Josiah Carlson wrote, in reply to me:

You seem to have missed the point of function decorations entirely. We already have what you offer in current Python syntax. The point was to move decorations to near/next to the function signature.

No, that was only part of the point. That it's part of the point is why I still prefer the list-before-colon syntax, which seems to me to go furthest towards keeping all information about the interface of a function together. And yes, I know that Guido finds that syntax unacceptable.

Read the PEP: http://www.python.org/peps/pep-0318.html

I have read the PEP, thanks. Heck, I'm even named in it. (I think I was the first person to propose a generalized decoration facility for Python, rather than just special syntax for a few special cases such as static methods. And, for what it's worth, the list-before-colon syntax was my proposal. Not that it matters much who thought of what, but I do think it's a bit off to tell me that I've "completely missed the point" of something I *invented*.)

...

I actually quite like this. It seems more Pythonic than the @foo proposal. Its obvious problem is that it involves something that looks at first glance like an ordinary suite of statements or expressions, but whose interpretation is substantially different. At least the @foo proposal avoids that.

What you like is what has existed with Python since the beginning.

No, it is not. What has existed with Python since the beginning involves redundancy: def f(...): ... f = decorate_somehow(f) requires three instances of the name of f. If you have N decorators it requires 2N+1 instances of the name of f. Not a big deal when the name is "f", but not so good if it's "build_interface_subgraph" or something. Not even great when the name is "f": what if you decide to rename it "g"? *And* it's ugly. These are reasons to want something else, even without the issue of putting all the "interface" information together. -- g