[Python-Dev] 2.4a2, and @decorators

Guido van Rossum guido at python.org
Tue Aug 3 19:00:22 CEST 2004


> In my view, the strongest point in favor of a solution that involves
> calling functions rather than changing syntax is that the functions
> involved can be placed in the standard library rather than the
> interpreter.
> 
> I believe a widely held view is that features can be supported by
> the stdlib do not merit language changes?

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.

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 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.

--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list