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

[Phillip J. Eby]

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.