[Python-Dev] Re: PEP 318: Decorators last before colon (original) (raw)

Phillip J. Eby pje at telecommunity.com
Wed Mar 31 19:16:06 EST 2004

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 someObjectiveCSelectoryesTheyCanBeThisLongsometimesLonger(takes, > some, args, here): > pass > someObjectiveCSelectoryesTheyCanBeThisLongsometimesLonger = > objc.selector(someObjectiveCSelectoryesTheyCanBeThisLongsometimesLonge > 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 someObjectiveCSelectoritsReallyLong(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.

More information about the Python-Dev mailing list