[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