"as" keyword woes

Carl Banks pavlovevidence at gmail.com
Tue Dec 9 13:20:27 EST 2008


On Dec 9, 7:48 am, Paul Boddie <p... at boddie.org.uk> wrote:
> On 9 Des, 14:24, Steven D'Aprano <st... at REMOVE-THIS-
>
> cybersource.com.au> wrote:
>
> > That is not what Guido said. What he actually said was:
>
> > "That's possible with sufficiently powerful parser technology, but
> > that's not how the Python parser (and most parsers, in my experience)
> > treat reserved words."
>
> I accept that many parsers are operating on predetermined tokens where
> keywords will already have been identified as such, regardless of
> their eventual syntactic context, by the time the parser gets to see
> them. What I wanted to point out was that other approaches are not
> exactly unheard of or particularly rare. Every now and again, the
> language gets extended and new keywords are sought in an excruciating
> process akin to a group writing exercise involving the existing
> keywords. A better parsing framework would alleviate these problems.

And introduce an assload of new ones.


> > What Guido is saying is that even if he agreed with the OP he couldn't
> > add that feature. He's not saying that he agrees with the OP. The Zen
> > gives good reasons for believing that even if Python's parser was
> > sufficiently powerful, he'd still consider the feature undesirable.
>
> Well, I think it's more interesting to explore the boundaries of what
> can be done, to debunk notions that such things aren't being done in
> the mainstream, and to examine whether they could benefit usability,
> than it is to defer to the Zen of Python as some kind of prescriptive,
> near-religious text at every turn.

As GvR mentioned in this thread, someone already did that with regard
to "parsing frameworks", and the result was PL/1.

Seriously, that's not a good thing.  To hell with the parser, what is
everyone focusing on the parser in this thread?  What about the human
reader?  Do you want the human reader to have to have all kinds of
rules to memorize about when a symbol is an identifier and when it's a
syntactic element?  Do you want people to have to learn when to escape
a symbol so that the parser treats it as an identifier instead of
syntax?

I'm not saying "as" alone was causing that--for once again Python
showed what the best way to enter unpleasant waters is: with a lot of
restraint--but a "better parsing framework" that eliminated keywords
would cause lots of confusion.

And finally: it's just plain bad style to use a syntactic element as
an identifier, even when allowed.


Carl Banks



More information about the Python-list mailing list