[Python-Dev] 2.4a2, and @decorators

[Jp Calderone]

Guido van Rossum wrote:
> 
> No viewpoint ought to be held to the exclusion of all others.  Using
> functions with "action-at-a-distance" through sys.settraceback may be
> okay for an obscure feature that can't be had any other way yet
> doesn't merit changes to the language, but that's not the situation
> for decorators.  The widely held view here is that decorators need to
> be added as a syntactic feature to avoid the problems with the postfix
> notation used in 2.2 and 2.3.  Decorators are slated to be an
> important new language feature and their design needs to be
> forward-looking, not constrained by what can be implemented in 2.3.

   Just to be clear, the implementation I shared did not use 
sys.settrace().  It did rely on inspect.currentframe(), but so do a 
handful of other stdlib modules (as PJE pointed out).

> 
> One important feature of @deco (and of [deco] prefix as I proposed it)
> is that it is a compile-time feature.  This has all sorts of
> advantages, since future compilers and tools will be able to know more
> about methods.  Solutions based on sys.settrace fail badly here.
> 
> 
>>Moreover, I have the impression that many people are clamoring for
>>this feature, no matter how it ends up looking, because they simply
>>*must have it*.  Well, if they must have it, why wait for 2.4, when
>>clearly they can have it right now?
> 
> 
> Sure, but that's not an argument against improving their situation in
> 2.4.

   If it is truly an improvement.  Here we (and many others) disagree.

   I like Python(*) because it is simple and generally unsurprising.  I 
think that '@deco' adds complexity, both for beginners and experienced 
programmers alike, so I do not see it as an improvement.  I am content 
with "foo = deco(foo)" and various metaclass-based automatic 
decorations, and see no need for them to be moved into the core.  I may 
be free to not use the '@deco' syntax in 2.4, but that will not prevent 
me from having to read it in the code of others, or from explaining it 
to other Python programmers.

   None of these are new points, so I don't expect a response to them.

> 
> If I had any hope that something better than @deco was possible but
> hasn't been discovered yet, I'd be holding off too.  But I don't think
> that's the case.  Every solution proposed has its own set of
> drawbacks, and the drawbacks aren't getting resolved by waiting.

   How many features that everyone hates can Python support?

   The Zen of Python might state that practicality beats purity, but if 
it continues to do so, time after time, at some point we're going to 
look up and wonder where that clean, readable, maintainable programming 
language we all loved has gone.

   Jp

  (*) And I really do like Python.  A lot.  Of the software I now write, 
at least 99.9% of it is in Python. The developers of this language 
_almost_ always show more good sense, intelligence, and skill than most 
other groups I can think of.  You all deserve more praise than you're given.