tweaking @decorator syntax
Christopher T King
squirrel at WPI.EDU
Wed Aug 4 20:07:24 CEST 2004
(warning, long rant follows)
On 4 Aug 2004, Sandy Norton wrote:
> Perhaps, you can eliminate the '@' alltogether:
I was thinking the same thing, only using a keyword in place of '@' rather
than dropping it entirely:
decorate classmethod, somethingelse:
I haven't seen this, or any of your proposals previously mentioned
anywhere (which doesn't mean they haven't been considered and rejected,
since the @ syntax was kept a good secret until it made it into 2.4a2).
Another proposal was to use a 'using' keyword like this:
But this was shot down because (from PEP 318):
The function definition is not nested within the using: block making it
impossible to tell which objects following the block will be decorated.
Okay then. Your & my syntaxes fix this problem nicely.
Nesting the function definition within the using: block suggests
nesting of namespaces that doesn't exist. The name foo would actually
exist at the same scope as the using: block.
This arguments seems to apply to our syntaxes, but... it turns out it's
not an argument at all! 'if' doesn't nest namespaces. Neither does
'for', 'try', 'while', etc. Only function and class definitions nest
namespaces; I wouldn't expect anything else to.
Finally, it would require the introduction of a new keyword.
This would apply to my idea, but frankly, I don't see how introducing a
new keyword in order to introduce a MAJOR language feature is any
different that introducing the butt-ugly '@' syntax, save that it may
cause conflicts with older code, in which case we should save decorators
for 3.0 (which IMAO should be the case anyways).
I'd like to continue this thread by suggesting another idea, side-stepping
a backwards-incompatible syntax change:
This has the following advantages:
1) No new syntax or keywords.
2) No nesting issues.
3) Follows a previous precedent (docstrings).
4) Implementable in pure Python for great backwards-compatibility
(http://users.wpi.edu/~squirrel/temp/decorate.py for a proof-of-concept)
5) Near the top of the function, so it is quite visible, but below the
function name, so it doesn't take attention away from what's important.
And the following disadvantages:
1) No new keyword/syntax means looking at it and saying "what's that?"
2) Will run without immediate error in older Pythons, possibly causing
3) Guido won't like it.
Of course, I prefer the nested block idea better (either with a new
keyword or new syntax), but I don't see those (especially the syntax one)
flying anytime soon.
Unless someone can come up with an idea everyone can agree on Real Soon
Now, I think the whole idea should be dropped and wait until 3.0. We'll
have plenty of time to argue about it then.
Sorry about the long rant, but it felt good to get that all off my chest.
More information about the Python-list