[Python-Dev] Property syntax (Re: [Python-Dev] Extended Function syntax)

[Guido van Rossum]

> [Guido van Rossum]
> >>> Actually I was attempting to find a solution not just for
> >>> properties but for other situations as well.  E.g. someone might
> >>> want to define capabilities, or event handlers, or ...
> 
> [Greg Ewing]
> >> But anyway, here's another idea:
> >> 
> >>   def foo as property:
> >>     def __get__(self):
> >>       ...
> >>     def __set__(self, x):
> >>       ...
> 
> [Guido van Rossum]
> > I don't like things that reuse 'def', unless the existing 'def'
> > is a special case and not just an alternative branch in the grammar.
> 
> I think Greg's idea ("as" or "is") could satisfy these conditions well
> (generic solution, and unadorned "def" as special case).
> 
> A standard function definition (simple, unadorned "def") is
> equivalent to:
> 
>     def f as function:
>         suite

In this syntax, where does the list of formal parameters go?

Also, this requires that the scope rules for the suite are exactly as
they currently are for functions (including references to non-locals).

That's all fine and dandy, but then I don't understand how the poor
implementation of property is going to extract __get__ etc. from the
local variables of the function body after executing it.

> A standard method definition is as above, or if a distinction is
> required or useful it could be equivalent to:
> 
>     def m(self) as method:
>         suite

OK, I can buy that.

I've got a little bit of philosophy on the use of keywords vs.
punctuation.  While punctuation is concise, and often traditional for
things like arithmetic operations, giving punctuation too much power
can lead to loss of readability.  (So yes, I regret significant
trailing commas in print and tuples -- just a little bit.)

So I can see the attraction of placing "as foo, bar" instead of "[foo,
bar]" between the argument list and the colon.

> This syntax could be used to remove a recent wart, making generators
> explicit:
> 
>     def g as generator:
>         suite
> 
> Of course, it would be a syntax error if the generator suite didn't
> contain a "yield" statement.

But then 'generator' would have to be recognized by the parse as a
magic keyword.  I thought that the idea was that there could be a list
of arbitrary expressions after the 'as' (or inside the square
brackets).  If it has to be keywords, you lose lots of flexibility.

> This syntax has aesthetic appeal.  I know nothing about its
> implementability.

That's too bad, because implementabilty makes or breaks a language
feature.

> What namespace these new modifier terms would live in, I also don't
> know.  The syntax proposal reads well and seems like it could be a
> good general-purpose solution.

The devil is in the namespace details.  Unless we can sort those out,
all proposals are created equal.

--Guido van Rossum (home page: http://www.python.org/~guido/)