[Python-Dev] Re: PEP 318: Decorators last before colon

[Bob Ippolito]

On Mar 31, 2004, at 1:59 PM, Michel Pelletier wrote:

>> Message: 1
>> Date: Wed, 31 Mar 2004 18:10:23 +0200
>> From: Simon Percivall <s.percivall at chello.se>
>> Subject: Re: [Python-Dev] Re: PEP 318: Decorators last before colon
>
> I've been following this discussion closely and I would like to voice  
> my
> opinion.
>
> Please don't add any decorator syntax to Python, at least not yet.  All
> of the proposals I have seen so far are, to be blunt, and in my opinion
> of course, ugly and are getting uglier as the discussion ensues.
>
> I see nothing wrong, at least for the present, with the status quo
> decorators that follow a function or class definition.  They are
> explicit, functionally equivalent, use the existing and completely
> understandable syntax, and are so rarely used by only the *most*
> experienced and advanced programmers that violating the beauty of the
> language is unjustified.

I've been pretty quiet about this lately because the discussions have  
gone into space, largely by people who don't even have a need or desire  
for decorators, but uninformed comments like this just irk me.

Decorators *are not rare* and are *used by regular programmers* in some  
problem domains.  Yes, it takes an advanced programmer to write such a  
framework, but that doesn't mean that the syntax is useless to  
non-advanced programmers.  It's particularly applicable to applications  
using PyObjC or ctypes where the function simply will not work unless  
it's decorated with the correct type signature.  It can also  
potentially make pure python frameworks such as Twisted, ZopeX3, or  
PEAK easier to use, by moving boilerplate wrapping stuff into  
decorators.  Decorators solve a *huge* problem with the current syntax:

def someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_(takes,  
some, args, here):
     pass
someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_ =  
objc.selector(someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonge 
r_, signature='some type signature')

versus (Guido's latest suggested syntax, which I approve of, even  
though I prefer the after-args-brackets):

[objc.selector(signature='some type signature')]
def someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_(self,  
some, args, here):
     pass

Please understand that just because you haven't need them yet doesn't  
make them worthless, ugly, etc.  It has nothing to do with being an  
experienced or advanced programmer, some problem domains simply REQUIRE  
decorated functions in order to work at all.  If decorators do not make  
Python 2.4, that is another major release cycle that extensions such as  
PyObjC and ctypes will be hampered by lack of syntax... to the point  
where I'd be inclined to just fork Python (or Stackless, more likely)  
in order to get the syntax.

-bob