tweaking @decorator syntax

[Christopher T King]

(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:
     def somefunc(self):
         pass

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:

 using:
     classmethod
     somethingelse
 def somefunc(self):
     pass

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:

 def somefunc(self):
     [classmethod, somethingelse]
     pass

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
   hard-to-track-down bugs.
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.