"as" keyword woes

MRAB google at mrabarnett.plus.com
Tue Dec 9 15:28:51 CET 2008

Paul Boddie 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.
> [Car analogy cut]
In some languages (I think Delphi is one of them - it's been a while!) 
some words which would normally be identifiers have a special meaning in 
certain contexts, but the syntax precludes any ambiguity, and not in a 
difficult way. "as" in Python was one of those.

I certainly wouldn't want something like PL/I, where "IF", "THEN" and 
"ELSE" could be identifiers, so you could have code like:

         THEN = ELSE;
         ELSE = IF;

See http://en.wikipedia.org/wiki/PL/I_(programming_language).

>> 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.
> Paul
> --
> http://mail.python.org/mailman/listinfo/python-list

More information about the Python-list mailing list