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

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