[Python-Dev] Re: PEP 318: Decorators last before colon
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 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.
More information about the Python-Dev
mailing list