JP commented
on the @decorator syntax recently checked in to a Python alpha. I agree
with him. Moreover, despite the fact that Guido has pronounced such
agreement futile, I agree with Jim
Fulton and I think that this should be a library issue, not a language
issue. (Does anyone think it's peculiar that the authors of two of the most
popular chunks of free Python software who have a very limited history of
agreeing with each other, agree on disagreeing with Python's designer on
language features like this?)
The thing that's most disappointing to me in this is that I had finally come
around to accepting the community's rationale against macros: that it was
too dangerous to allow arbitrary changes to Python's syntax because it would
make the local languages confusing and it would make the resulting language
harder to learn and harder to document.
The need for macros doesn't go away, though, and technical necessity becomes
distorted by social pressures. I believe that Python could benefit from a
lot of different syntax additions, most notably block syntax and
continuation syntax, to facilitate programming in the asynchronous model
that Twisted uses. I can't add these myself, though, because Python doesn't
provide the necessary hooks, and I don't have the patience to agitate on
python-dev until my pet feature is added, unlike some people.
I haven't run the numbers, but I imagine that something like one out of
every ten thousand methods I write is decorated in some way. Closer to one
in five is an asynchronous callback. Why is it that the extra convenience of
one-character syntax is necessary for this task which is extremely uncommon?
Apparently because other people in completely different application domains
find it is more common for them, and those people are more willing to spill
gallons of virtual ink complaining about the inconvenience and unreadability
of writing "decorate(hello)" vs. "@hello".
I think it is a bigger deal that I have to write ".addCallback(lambda x:
doSomething())" rather than "wait; doSomething()", but I don't have the
fortitude to convince Guido that "something is better than nothing" in this
case. I have been hoping for years that "something" would arrive in the
language.
These kind of ad-hoc language modifications strike me as more dangerous than
a real, powerful macro system, because they don't just pollute the language
for some people, they pollute it for everyone at once because of some
people's needs. You have to hack Guido's brain, not the interpreter, to
implement your macros, which is both more time-consuming and more
detrimental to the community as a whole. Macros increase complexity locally
and utility locally; a static language decreases complexity globally and
utility globally, but every time someone successfully pushes through a
feature like this, they increase complexity globally but utility locally.
It's the worst of both worlds.
Of course I'm exaggerating. This feature in particular is not very
worrisome, but the trend it indicates is.
The strange thing is that I really don't understand Python's design when
things like this get bolted on to the side. Every time I think I've finally
got the "pythonic" vibe something weird like this happens. I suppose that's
what makes this feature so bad to me. I don't know why I am disagreeing with
Guido, because I don't understand the aesthetic he's using to make this
decision. From what I can tell just using the language and reading
python-dev, it's more or less random.
I hope I'm wrong. I was wrong about the new object model (except __class__
mutation!), and I'm grateful for that every day. Still, even after reading a
lot of the ranting, it seems to me that the @decorator syntax is being added
because it's easy, not because it's important.