[Python-Dev] Re: PEP 318: Decorators last before colon
Bob Ippolito
bob at redivi.com
Wed Mar 31 15:04:18 EST 2004
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
More information about the Python-Dev
mailing list