[Python-Dev] PEP 318: Decorators last before colon
Phillip J. Eby
pje at telecommunity.com
Wed Mar 31 16:12:54 EST 2004
At 12:49 PM 3/31/04 -0800, Guido van Rossum wrote:
> > There appears to be a strong correlation between people who have
> > specific use cases for decorators, and the people who want the
> > last-before-colon syntax. Whereas, people who have few use cases
> > (or don't like decorators at all) appear to favor syntaxes that move
> > decorators earlier. Whether that means the "earlier" syntaxes are
> > better or worse, I don't know. <0.5 wink>
>
>Maybe the practitioners are so eager to have something usable that
>they aren't swayed as much by esthetics.
I appreciate the aesthetics of the new syntax, it's just the little
implementation nits that bother me. And it just seems so un-Python to have
a special syntax that doesn't start with an introducing keyword.
> > I'll assume your intent is to prevent decorators from biting the
> > unwary -- specifically people who *don't* use decorators a lot and
> > therefore are not looking for them. I will therefore focus now on
> > the issues with the "previous line" syntax that may bite people,
> > with an eye to how they might be fixed.
>
>They should still be very unlikely to accidentally create one.
>
>With proper vertical whitespace, the fact that a decorator list
>(written properly) means something special should be obvious to even
>the most casual observer: there should be a blank line before the
>decorator list and none between it and the 'def' line.
>
>The human brain is a lot more flexible in picking up patterns than the
>Python parser; as shown many times in this discussion, most people
>have no clue about the actual syntax accepted by the Python parser,
>and simply copy (and generalize!) patterns they see in examples.
>
>My goal is to help people grasp the gist of a particular construct
>without having to think too much about the exact syntax; within all
>sorts of other constraints of course, like being parsable with the
>simple ans stupid LL(1) parser, and being easy to grep (in some
>cases).
I previously thought these were related. That is, I thought that keeping
it to an LL(1) grammar was intended to make it easier for humans to parse,
because no backtracking is required. But, the new syntax *does* require
backtracking, even on the same line. Granted that humans don't literaly
read a character stream the way a parser does, isn't this still the first
piece of backtracking-required syntax in Python?
>I hadn't thought of those, but the new situation can't be worse than
>before (decorations following the 'def'). Usually these tools either
>use some ad-hoc regex-based parsing, which shouldn't have any problems
>picking out at least the typical forms, or they (hopefully) use the
>AST produced by the compiler package -- it should be possible for that
>package to modify the parse tree so that decorators appear as part of
>the Function node.
Good point. Will this be true for the AST branch's AST model as well?
> > It seems like the main complexity would be the possibility of having
> > to duplicate a number of levels of containing rules for
> > 'restofliststmt'. But maybe I'm completely off base here and
> > there's no sensible way to define a correct 'restofliststmt'.
>
>You can assume that's the case. :)
Yeah, I just spent a few minutes taking a look at the actual parser
implementation. :( For some reason I thought that the simple LL(1)
grammar meant there was also a simple recursive-descent parser. I'd
completely forgotten about 'pgen' et al.
More information about the Python-Dev
mailing list