Python's Secret Macro Mechanism

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.