On Aug 2, 2004, at 12:55 PM, Phillip J. Eby wrote:
I would think the fact that the '[decorators]' syntax can be implemented in pure Python (no changes to the interpreter) for existing Python versions would give more weight to it. That is, if someone wants to implement a decorator that's forwards and backwards-compatible, that's possible with the list syntax, but not the @ syntax.
First off, let me just say I'm happy *one* proposal was selected for inclusion. The @foo on the line before the function was not my favorite, but that's okay. It'll definitely work. However, I do think [decorator...] on the line before the function definition would be a far worse choice than @decorator. Decorators *are* special new syntax. At least @foo *looks* like new syntax. [decorators] looks like a expression creating a list, but instead is completely magical. Magical syntax seems very poor to me. About the only advantage it has is that you can implement it via a completely horrible hack in Python < 2.4. But, that is only a temporary situation. In a few years everyone will have Python >= 2.4 and we'd still be stuck with strange weird syntax that doesn't look like syntax. The one thing I do dislike about the new addition is the arbitrary (?) restriction on expression allowed in a decorator. From Grammar.. decorator: '@' dotted_name [ '(' [arglist] ')' ] That seems quite odd to me. Is there some reason it couldn't be: decorator: '@' test ? I don't see how that would cause a problem, but maybe I've missed something. Just testing out how this syntax looks, you can ignore the rest of this mail. :) @classmethod @arguments(string, int) @returns(list) def foo(s, i): return [s]*i or perhaps the same, but with a list allowed: @classmethod, arguments(string, int), returns(list) def foo(s, i): return [s]*i or original proposal: def foo(s, i) [classmethod, arguments(string, int), returns(list)]: return [s]*i Ah well, they all have their advantages. :) This one is workable. James