[Python-Dev] Re: Call for defense of @decorators (original) (raw)

Christian Tismer tismer at stackless.com
Sun Aug 8 20:30:30 CEST 2004

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/

More information about the Python-Dev mailing list