[Python-Dev] Call for defense of @decorators

["Martin v. Löwis"]

Gustavo Niemeyer wrote:
> - Decorators are going in on 2.4.

Yes, that's the current status. Of course, it is difficult to
predict, especially the future. Who knows what would happen
if people find flaws in the proposed syntax, and no alternative
is available?

> - There are two obvious usage cases for decorators: static and
>   class methods;

Correct.

> - There are more complex usage cases for decorators such as
>   PyObjC which was already agreed to be something necessarily
>   supported in the implementation;

Correct.

> - People which want the powerful decorators don't care about
>   the syntax, as far as the feature is implemented;

Some actually do care about the syntax as well.

> - Adapting external tools should not be used as an argument;

No, external tools need to be considered. Preferably in the
concrete, not in the abstract.

> - We're clearly unable to get into a consensus about syntax;

Yes. I believe this is not specific to this change - people
*always* argue about syntax.

> - All current syntax vs. problems to solve have been discussed
>   extensively;

Yes.

> - There are bizarre usage cases of the current decorator
>   implementation, but this is something which is considered
>   abusive and won't affect decisions since should be casual;

Yes.

> - The @ character is used in at least two tools (Leo, IPython),
>   and this is being considered as something bad, but not a
>   show stopper;

This is certainly bad. Whether it is a show-stopper, I don't know.
I don't understand the Leo issue; I thought it would use the @
syntax only within Python comments, in which case there would be
no conflicts.

> - The perlish argument is non-sense;

Yes. In a typical decorator, the only special characters on
the line will be the @ and possibly () (perhaps also commas
between arguments). This is completely unlike Perl which
often has large fractions on special characters on a line.

> I belive that either some different syntax which most
> people agree upon is raised, or we're done.

Perhaps. People really should use it to find potential flaws
in the semantics of decorators, e.g. things you ought to be
able to do with decorators but can't. Of course,
test_decorators.py already gives a good idea what is possible,
so it might be "good enough".

Regards,
Martin