On Fri, Jan 31, 2003 at 01:21:03PM -0500, Guido van Rossum wrote:
> > > 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.
class C(X, Y):
suite
<=>
def C(X, Y) as type:
suite
<=>
C = type('C', (X, Y), CODE, GLOBALS)
The type constructor currently expects a dictionary as third argument.
It will need to be modified to do the equivalent of:
class_namespace = {}
exec CODE in class_namespace, GLOBALS
And class_namespace will be initialized to the equivalent dictionary.
For functions:
def F(args...):
suite
<=>
def F(CODE, GLOBALS, 'F', ARGDEFS) as function:
suite
<=>
F = function(CODE, GLOBALS, 'F', ARGDEFS)
CCed to the PyPython list because looking at the creation of function
and type objects this way may help bootstrapping - the 'function'
and 'type' factories could be written in Python using some kind of
more primitive callable construct added as a crutch for PyPython.
Oren
