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

[Phillip J. Eby]

At 06:43 PM 3/31/04 -0500, Neil Schemenauer wrote:
>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.

It sounds like a lot of people's "use" translates to your "abuse"; e.g. 
Bob's use cases would certainly have to be considered abuse, since they 
wouldn't be part of some fixed set defined by Python.


> > 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.

And it doesn't do what's needed, since you left out the rebinding of the 
function name.  That is, you would have to do:

someObjectiveCSelector_yesTheyCanBeThisLong_sometimesLonger_ 
=  objc.selector(_, signature='some type signature')

So only one typing of the name is saved.

Finally, it doesn't address the issue of wanting to call these things out 
*ahead* of the function's code, as part of the definition header, so that a 
person who is reading for an overview can notice it and take it in.


>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.

There's no such thing, since it's specifically a syntactical change that's 
desired.  Obviously it is *possible* to use decorators today.  The desired 
change is that they be easy for someone to see when they are skimming 
through code.

Ugly or not, *all* of the proposed syntaxes that don't involve creating an 
extra suite have the practical effect of improving the semantic readability 
of decorator use over today's Python.  In addition, they also have the 
practical effect of making decorator use more convenient, since the two 
extra repetitions of the function or class name go away.

I suspect this is part of why there is such disagreement on the subject of 
decorators: people who make heavy use of them today know exactly what 
problems today's syntax has from both the readability and writability 
viewpoints.  Whereas people who do not use them, don't get why limiting 
their use to fixed subsets, or single decorators, or any number of other 
ideas just negate the usefulness of having a syntax in the first 
place.  Or, like Michel, they don't see a point to having a syntax at 
all.  Well, that's certainly understandable, and if light users' objection 
was "we're going to have to read your stinkin' decorators so we want 'em 
really visible", I would totally understand and support that direction.

But, instead, a lot of the syntax directions and arbitrary restrictions and 
"why do we need a syntax" aren't really helpful for heavy users of 
decorators.  We know what we want, and MWH already implemented a patch some 
time ago that does exactly what we want.  I think most of us are willing to 
compromise to Guido's syntax if that's what it takes to get a syntax that 
meets our primary goals, even if leery about the potential 
consequences.  (Because even though most people learn by example, Python's 
appearance of having consistent and sensible rules is what initially hooks 
many of us on using it.)

But, there's really no point in arguing that no decorator syntax is 
needed.  That would be like arguing that there is no point to having 'for' 
loops because you can emulate them with 'while'!  Given that Python 2.2 
introduced the usefulness of decorators, and 2.3 was a "no new syntax" 
release, Python 2.4 is the logical release to add a decorator syntax.  And 
now, therefore, is the time to get a syntax approved.

Personally, if I'd realized that the original PEP 318 syntax 
(last-before-colon) was so controversial, I'd have been campaigning for it 
a lot sooner than now.  I somehow assumed that it was a "done deal" as far 
as having tentative BDFL support from way back.