On Aug 3, 2004, at 10:40 AM, Guido van Rossum wrote:
I have a gut feeling about this one. I'm not sure where it comes from, but I have it.
I guess I have the opposite gut feeling: special classes of expressions in the grammar are always bad. Michael Chermside's message said this better than I can. Heck, even 'except' can take an arbitrary expression as an argument! Now I'm damn sure I'd never write code that says except FooError and f() or MyErrors[5]: because that would be insane, but I'm glad python doesn't restrict the argument to some strange subset of expressions that someone decided were approved! Consistency of grammar is a key feature, even when it allows users to write insane programs.
It may be that I want the compiler to be able to recognize certain decorators.
If I understand what you're saying, it seems that you're thinking the @ form should be more a static declaration, not a dynamically evaluated expression, so that the compiler can reason about it without running code. However, that isn't the case even now, and if it was, it wouldn't fit in with the rest of the python language very well. Definitely an interesting idea, but I think it would require the @'s argument to be a compile-time macro, instead of a run-time expression. And python doesn't have compile-time macros. With @ taking a runtime expression, I don't see how the compiler could possibly do anything with its argument. Nothing can be guaranteed. As a postscript, I must say I am alarmed by some comments others have used to justify the current restricted state. In particular (paraphrased), "it's good because it keeps people from using lambda", and "it's good because it keeps people from doing '@1+1' by mistake. For the first: you hate lambdas so much? They are in python -- arbitrarily forbidding their use in certain expressions because you don't like them is pretty strange. For the second: You want to do type checking via syntax error?! *That* is insanity. And it doesn't even work well (of course). James