[Python-Dev] Re: PEP 318: Decorators last before colon
Neil Schemenauer
nas-python at python.ca
Wed Mar 31 18:43:12 EST 2004
On Wed, Mar 31, 2004 at 03:04:18PM -0500, Bob Ippolito wrote:
> On Mar 31, 2004, at 1:59 PM, Michel Pelletier wrote:
> >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 agree with Michel. The decorator syntax being discussed looks
ugly. I think it would be okay if the set of valid decorations were
limited to 'classmethod', 'staticmethod' and maybe a few others.
Allowing more general expressions seems to asking for abuse.
> 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')
I would be happer if there was an easier way for you to do what you
want _without_ introducing new syntax to that language. For
example, what if '_' was bound to the last defined function? You
could then do something like this:
def someObjectiveCSelector_itsReallyLong_(takes, some, args, here):
pass
objc.selector(_, signature='some type signature')
That looks pretty nice and is even shorter to type than the proposed
syntax.
> Please understand that just because you haven't need them yet doesn't
> make them worthless, ugly, etc.
I don't think Michel is saying they are worthless. However, the
proposed syntax is highly contentious. It would be good if there
was a short term solution that wouldn't require new syntax. That
would give Guido and the Python community time to figure out the
best syntax.
Neil
More information about the Python-Dev
mailing list