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

[Christian Tismer]

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/