[Python-Dev] Call for defense of @decorators
Gustavo Niemeyer
niemeyer at conectiva.com
Thu Aug 5 23:53:31 CEST 2004
> Depends on in what direction you want to make a change. It
> appears you want to avoid introducing any kind of syntax
> change. In that case, you should explain people how to spell
> classmethod and synchronized in a more convenient way, because
> that is what the stated motivation of PEP 318 is - you would
> have to explain why this motive is bad, irrelevant, or otherwise
> not a worthy goal.
>
> Or you could argue on a procedural basis: regardless of whether
> the feature is good or bad, the current implementation is
> unacceptable, as the PEP does not correspond with the
> implementation, the syntax is undocumented, the code has no test
> cases, and so on. I'm actually going to do that, because I do
> think the process is unacceptable, and should be either corrected
> or reversed (of course, this says nothing about the feature itself,
> or the code implementing it).
Ok, I'll try to summarize the current status of the feature
so that I (and others) can understand if there's something to
be done:
- Decorators are going in on 2.4.
- There are two obvious usage cases for decorators: static and
class methods;
- There are more complex usage cases for decorators such as
PyObjC which was already agreed to be something necessarily
supported in the implementation;
- People which want the powerful decorators don't care about
the syntax, as far as the feature is implemented;
- Adapting external tools should not be used as an argument;
- We're clearly unable to get into a consensus about syntax;
- All current syntax vs. problems to solve have been discussed
extensively;
- 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;
- The @ character is used in at least two tools (Leo, IPython),
and this is being considered as something bad, but not a
show stopper;
- The perlish argument is non-sense;
I belive that either some different syntax which most
people agree upon is raised, or we're done.
--
Gustavo Niemeyer
http://niemeyer.net
More information about the Python-Dev
mailing list