PEP 318 (was Re: [Python-Dev] Re: Guido's Magic Code was: inlinesort option)

Phillip J. Eby pje at
Mon Nov 3 20:09:55 EST 2003

At 11:02 AM 11/4/03 +1100, Delaney, Timothy C (Timothy) wrote:
> > From: Alex Martelli [mailto:aleaxit at]
> >
> > BTW, when we do come around to PEP 318, I would suggest the 'as'
> > clause on a class statement as the best way to specify a metaclass.
>I just realised what has been bugging me about the idea of
>     def foop() as staticmethod:
>and it applies equally well to
>     class Newstyle as type:
>Basically, it completely changes the semantics associated with 'as' in 
>Python - which are to give something a different name (technically, to 
>rebind the object to a different name).
>OTOH, the first case above means 'create this (function) object, call this 
>decorator, and bind the name to the new object'. So instead of taking an 
>existing object (with an existing name) and rebinding it to a new name, it 
>is creating an object, doing something to it and binding it to a name. A 
>definite deviation from the current 'as' semantics, but understandable.
>However, the second case above is doing something completely different. It 
>is creating a new object (a class) and binding it to a name. As a side 
>effect, it is changing the metaclass of the object. The 'as' in this case 
>has nothing whatsoever to do with binding the object name, but a name in 
>the object's namespace.
>I suppose you could make the argument that the metaclass has to act as a 
>decorator (like in the function def above) and set the __metaclass__ 
>attribute, but that would mean that existing metaclasses couldn't work. It 
>would also mean you were defining the semantics at an implementation level.
>I'm worried that I'm being too picky here, because I *like* the way the 
>above reads. I'm just worried about overloading 'as' with too many 
>essentially unrelated meanings.

Well, there's always 'is'...

def foop() is staticmethod:

class Newstyle is type:

Interestingly, this usage is rather similar to Eiffel, which IIRC 
introduces code suites with 'is', although I think without the modifier.

I'm not all that enthused about the metaclass usage, mainly because there's 
already an okay syntax (__metaclass__) for it.  I'd rather that class 
decorators (if added) were decorators in the same way as function 
decorators.  Why?  Because I think that correct, combinable class 
decorators are probably easier for most people to write than correct, 
combinable metaclasses, and they are more easily combined than metaclasses are.

More information about the Python-Dev mailing list