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

Christian Tismer tismer at stackless.com
Mon Aug 9 11:04:05 CEST 2004

Martin v. Löwis wrote:

Christian Tismer wrote:

What I added was yet another stuff entry for new-style classes. It may also appear on module level, like the metaclass feature works. While this "works", I still think it is a bad idea, for two reasons:

Just as a remark: You are shifting topic, now. We were not discussign what's nice or good or not, it was about a correct proposal, which I supplied. I was not intending to discuss if this is a good approach.

1. It only helps the parser, A human reader would have to scroll to the top of the class (or worse, to the top of the module) to find out.

compare slots, compare metaclass, and I mentioned already that these are intermediate construct, too.

2. For the author, it is redundant typing - the author knows this is a decorator, so having to type this again in full is redundant. 1 and 2 together make this a write-only syntax.

This argument is a little overdone. To repeat the function name just once isn't that bad.

3. It means that the parser has to recognize decorators This is not often the case; I believe the only other exception is future (which I also dislike, despite its cuteness). [As any good list of 2 reasons, this list of course has 3]

The parser doesn't have to recognize decorators. See the implementation of metaclass. This is a lookup of a name, like it happens already. But it is true, the parser then has to generate different code for the members of the decorators sequence.

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. There is a solution already: put the function wrappers after the declaration. The goal of this change is specifically to come up with a syntax. If no syntax could be find, it would be best not to change anything.

(**) That's of course a very good argument.

I'm not worried that the group cannot agree on syntax: people can never agree on syntax, not just in the case of Python. If you wait for agreement, you wait forever.

Ok. My real fear is that we get to a solution which will spoil Python's appearance in an unrevertable way, just because the relevant people are getting bored by discussion and want to stop it by supplying a premature solution.

...

It's not any more compatbible than the 2.4a2 approach: - old code (which does not use the feature) continues to work correctly (*) - new code (which uses the feature) won't work on old implementations. (*) Actually, there is a slight incompatibility in your approach: Code that used to run and used to raise an exception would, under your change, now suddenly succeed without exception.

I don't see it as a requirement that code that ran before, continues to run after a new construct is introduced. By adding decorators to your class, you decide to use this feature, you also change its implementation and put the decorators where you like them. Relying on exceptions which happened before the change is nothing that I want to be concerned with. Changing from old-style to new-style classes is also an operation that will cause small semantic differences, but I never heared someone arguing against this.

I don't think you need such far-fetched argumentation to kill this proposal. Stick with (**), it is convincing enough. :-)

ciao - 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