[Python-Dev] Re: Call for defense of @decorators

[Christian Tismer]

Martin v. Löwis wrote:

> Christian Tismer wrote:

[dropping things that I trashed while implementing]

>> To save *some* typing (laziness was also a driver for this
>> whole decorator nightmare), we could also remove the assignment
>> and just have a function call like
>>
>> classmethod(myfunc)
> 
> 
> This breaks backward compatibility. This is already legal
> syntax, and should raise a NameError if myfunc is not
> defined (actually, this holds for the first proposal, too).

This is correct. I failed to understand that, initially,
but when trying an implementation, I also found out that
I need something to make this unambiguous. Here it is.

What I added was yet another __stuff__ entry for new-style
classes. It may also appear on module level, like the
__metaclass__ feature works.

So what I implemented was special treatment for decorators
appearing this way:

class MyClass(object):

     __decorators__ = classmethod, staticmethod, otherdeco


     classmethod(mymethod)

     def mymethod(self, *args, **kwds):
         ...

The implementation intercepts all top-level occurances
of objects mentioned in the __decorators__ sequence
and treats the according statements as comments.
They are all collected through the whole class definition,
and put into an extra code object which is executed
after the class code has finished.
The generated post-code is of the form

     mymethod = classmethod(mymethod)

and for nested cases

     mymethod = otherdeco(classmethod(mymethod))

...

> Your proposals are all by no means little. They are significant,
> counter-intuitive changes of the language.

What I depicted above doesn't seem so counter-intuitive to me.
I don't claim it is *the* solution for the future, but it
is a compromize which gives me the desired effect, without
introducing new syntax, just a new __special_entry__. This
makes obvious that this is a temporary feature which should
be replaced by a better construct at some time, like __metaclass__
and __slots__ will probably, too.
But it provides a solution without enforcing us to decide
about new syntax right now, which appears to be too early
for a group that can't find a common denominator, yet.

> Also, try to come
> up with counter-proposals that are well thought-out, instead of
> being created in a rush.

No rush, just incomplete.
A side effect of this idea is that the decorator(funcname) items
can appear wherever you like them in the class definition.
I don't know if this is good. It might get used to advantage
if we use decorators to define interface-like stuff, for instance.
Then, a series of interface decorator "calls" might be put at
the top of the class.

My "implementation" is just a proof of concept. I didn't patch
the code generator yet or hacked bytecode, but did a little
source code transformation with he desired effect.
This is enough to get a feeling for proof-of-concept.
A drawback of this implementation is that the decorators
are taken literally. It won't work if you rename them
during the class definition.

For my purposes it works fine, but I don't claim that it fulfils
all other desired use cases. At least it is compatible, simple,
complete, implemented in a way, and works for my applications.

kind regards -- chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/