[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