[Python-Dev] Property syntax

[Aahz]

On Fri, Jan 31, 2003, Guido van Rossum wrote:
>Aahz:
>>Guido:
>>>
>>> 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
> 
> Um, the whole point of this syntax is that property, synchronized
> etc. do *not* have to be keywords -- they are just callables.
> 
> So the compiler cannot look at what the thunk is used for.  We need
> uniform treatment of all thunks.  (Even if it means that the thunk's
> consumer has to work a little harder.)

I'm not sure I agree with this assertion.  I think that there *do* need
to be different kinds of thunks.  Perhaps it's only necessary for there
to be two or three different kinds of generic thunks (at least "creates
new local scope" and "does not create new local scope").  Note that what
follows after the "as" need not be an actual Python keyword, but it does
need to be something significant to the parser/compiler, similar to the
way "from __future__" works.  I think that requiring thunk types to be
built into the language is reasonable.  If we're going the generic
route, we could do something like this:

    class C:
        def foo as (immediate, local) [property]:
            def __get__(self):
                ...

I suppose we could agree that all thunks create a new local scope and
that all thunks get executed immediately (like classes and modules, but
unlike functions), but I would prefer to not build that restriction into
the syntax.  If we don't agree on this (or on some other set of
properties that all thunks have), we can't have uniform treatment of
thunks as you desire.

It occurs to me that "thunk" would make a good keyword if we're adding
one.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

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