[Python-Dev] Property syntax

[Aahz]

On Fri, Jan 31, 2003, Guido van Rossum wrote:
> David Goodger:
>>
>> 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?

    def f(spam, eggs) as function:
        suite

> 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.

Sort of.  Each keyword can handle the thunk differently.  For the
property keyword, it'd be handled more similarly to a class.  In fact,
class then becomes

    def C as class:
        suite

>> 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.

You allow both.  The square brackets operate on the thunk (which is
probably all that's needed for classmethod and staticmethod); different
kinds of thunk parsing/compiling require keywords:

    def C as class:
        def foo(x) [staticmethod]:
            return x*2
        def bar(self, y) as generator:
            for i in y:
                yield self.foo(i)
        def spam as property [classmethod]:
            def __get__(cls):
            ...

The classmethod object would of course need to be able to differentiate
thunk kinds, assuming you wanted to allow this at all -- but it doesn't
require a syntax change to add class properties if they didn't exist.

>> 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.

The keywords go in the "defining thunk" namespace.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Argue for your limitations, and sure enough they're yours."  --Richard Bach