[Python-Dev] Questions about '@' in pep 318

[M.-A. Lemburg]

Guido van Rossum wrote:
>>In essence, you are proposing to reserve a new keyword. Solutions 
>>creating new keywords have been ruled out because they might break
>>existing code.
> 
> 
> Perhaps this could be addressed by requiring "from __future__ import
> decorators", for one release, just like was done for "yield".  I
> expect that this would be acceptable to the ObjC folks, too.  It
> wouldn't be my favorite, but I won't rule it out just because of the
> new keyword (and yes, this is a softening of my position on new
> keywords).

At EuroPython 2004 I had the impression that folks were not
really ready for a finalization on the feature. Your conclusion
at the conference was to wait for another release before making
a final decision which was well accepted by the audience.

With all the fuzz around this issue, I think that was a wise
decision and wonder why "something" now sneaked into 2.4a2.

Not being a big fan of decorative art, I'm a firm -0 on
whatever the final syntax may be, but just to throw in
an idea from someone who has not participated in all the
talk about decorator, here's some food for thought:

"""

1. Instead of trying to overgeneralize, we only allow exactly
    *one* decorator per function definition.

2. Since decorators change the definition of a function, that
    one decorator call is placed directly after the "def" and
    before the function name.

Examples:

def staticcounted(func):
     return staticmethod(countcalls(func))

class MyClass:

	def classmethod test1(selfclass, x):

	    """ Test method.
	    """
	    print x

	def staticcounted test2(self, x):

	    """ Test method.
	    """
	    print x

If someone needs more than one decorator or wants to do
funky stuff, it's easy enough to define a combining generator
for that particular need (see e.g. staticcounted).

The only argument I heard at the conference against placing
the decorator between the "def" and the function name was that
of losing the "grep'ability" in this case. I don't consider that
much of a loss, since it only applies to new code and
cases where you actually make use of decorators. The simple
nature of the syntax also guarantees that you can easily
modify your grep expression to accomodate for possible
decorators in front of the name (you'll only ever have one).

"""

If you don't like the idea, that's fine, but perhaps it
spurs some new thoughts of how to make this whole decorator
thing fit better the elegance of the language.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 06 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::