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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4