Ian Bicking: the old part of his blog


(Looking for More On Decorators?)

JP Calderone reports (disappointedly) that decorators in Python 2.4 will look like, I guess:

class Whatever(object):
def something(a, b, c): ...
Blech. @ is ugly and arbitrary and confusing. And seemingly out of the blue -- several much more reasonable alternatives were being discussed, I thought.

He suggests another technique, that can be applied even to Python 2.2 and 2.3, and looks like:

class Whatever(object):
__metaclass__ = DecoratableType
def something(a, b, c): ...
This looks okay to me (except the metaclass, but that's really an implementation detail). I'd rather it look like syntax, but I prefer a real word to @. Something I can pronounce, even if I'm only reading silently to myself.

Notably, this reminds me very much of Zope interfaces and adapters, which look something like:

class Whatever(object):
Or PyProtocols:
class Whatever(object):
All three are an extended kind of metaprogramming. All three work through nasty tricks, tricks that involve going into the calling frames, applying temporary metaclasses, and other bad stuff.

But it seems to me that all these cases are asking for another kind of meta-programming, something more compile-time, something a little less intrusive and a little more cooperative than metaclasses. While I would very much like decorators, I'd much rather wait until after 2.4 for a solution that covers all these issues. Especially since all of these issues are proven needs, as exemplified by the hacks that are already being put in place.

Created 03 Aug '04
Modified 25 Jan '05


I've added to comment to JP Calderone's post in defence of
@decorator. I won't repeat it
all here, except for this plea:
please try @decorator for a few
days and see if it grows on you.

Mark Russell
# Mark Russell

Anthony checked in the @ syntax today. He said that Guido's description included the phrase "a syntax we all hate equally".

Ho hum.
# Richard Jones

I think the key points are (1) the existing foo = decorator(foo) approach is the "backward compatible" answer - compatibility isn't the issue people make of it, (2) some people (notably the ObjC crowd) have a strong and specific need for something like this, and (3) the endless discussions have shown no sign of stopping, have never demonstrated a clear "preferred answer", and everyone is tired of them.

For better or worse, "we all hate equally" is the best around (short of sticking with foo = decorator(foo)).

[underwear class="flameproof"]
Having said this, you could make the same comments about the "conditional operator" discussions. Maybe Guido should have done the same thing there :-)
# Paul Moore

Well, Guido has always been clear on what decorator syntax he preferred. And in the old days, we used to trust his intuition; if he didn't like something, it stayed out of the language. That was, of course, what made Python so damn good.

I'm less impressed by the current design-by-arguing-until-nobody-cares-anymore approach. I really hope we won't see too much of that in the future...
# Fredrik

@something is ugly and unpythonic imho. Don't know if anybody has mentioned it, but I'd go with the decorator-block syntax, easy to spot, easy to read, and saves lot of typing.

class someclass:
decorator require_int, classmethod:
def foobar( a ):
def another( a, b, c ):
def a_normal( self ):
# Florian Bösch