[Python-Dev] 2.4a2, and @decorators
exarkun at divmod.com
Tue Aug 3 19:23:10 CEST 2004
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
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.
(*) 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.
More information about the Python-Dev