[Python-Dev] Re: Plea for function/method syntax sugar (PEP 318, with a different syntax)

[Bob Ippolito]

On Feb 19, 2004, at 2:45 PM, Thomas Heller wrote:

> "Phillip J. Eby" <pje at telecommunity.com> writes:
>
>> At 05:06 PM 2/19/04 +0000, Michael Hudson wrote:
>>> Bob Ippolito <bob at redivi.com> writes:
>>>
>>>> Also note that the patch also adds the same sugar to classes, so you
>>>> could use it in lieu of metaclasses for some cases (like 
>>>> transforming
>>>> some members that follow a naming convention into properties):
>>>>
>>>>>>> class Foo(object) [type]:
>>>> ...   pass
>>>> ...
>>>>>>> Foo
>>>> <type 'type'>
>>>
>>> FWIW, I'm rather less convinced this is useful.
>>
>> class Foo(object) [instancesProvide(IFoo)]:
>>      ...
>>
>> is actually somewhat more useful.  Right now, the packages that do
>> this sort of thing (Zope and PyProtocols) use a pseudometaclass in
>> order to spell it more like this:
>>
>> class Foo(object):
>>      protocols.advise(instancesProvide=[IFoo])
>>
>> Being able to spell it the other way would allow a less "magical"
>> implementation for various types of class metadata.
>
> But there is not really a dramatical advantage over this notation, with
> a suitable metaclass:
>
> class Foo(object):
>     __metaclass__ = SomeMetaclass
>     __provides__ = [IFoo]
>
> And my main question (top myself, maybe) with the change is:
>
> There should really be some killer features in 2.4 which allow to
> drop support for Python 2.2 and 2.3 in modules using this new syntax.
> None of the mentioned use cases apply to the standard library.

There needs to be an adapter implementation in the standard library at 
some point anyways (personal preference: PyProtocols).  Using 
metaclasses is unintuitive and troublesome because of the single 
inheritance restriction.  Try using mixins! :)

PJE's workaround for this is in PyProtocols is to have the advise() 
function do FAR too much magic (stack introspection, I think) and 
implements a temporary __metaclass__ that ends up removing itself as 
soon as the class is created.  I'm sure he would love to remove this 
gnarly code, and I'd love to not depend on it because it's fragile.  
For example, if you need a custom __metaclass__ and you accidentally 
put advise() before that declaration then your custom __metaclass__ 
gets ignored.

-bob