Reserved words as identifies (was Re: Long names are doom ?)

[Chris Gonnerman]

----- Original Message -----
From: "Alex Martelli" <aleaxit at yahoo.com>
Subject: Re: Long names are doom ?


> "Chris Gonnerman" <chris.gonnerman at newcenturycomputers.net> wrote in
message
> news:mailman.990935541.21263.python-list at python.org...
>     ...
> > This points toward one of my few complaints against Python:
> > the absolute restriction against using a reserved word as a
> > variable name *even if it is unambiguous*.  In particular,
>
> That's the definition of *reserved*, of course.  One language
> that tried to use keywords that were not reserved was PL/I,
> IBM's ambitious attempt in the '60s to make one language
> that would have all good points of Cobol, Fortran AND Algol
> plus more, and thereby become the only programming lang
> in the world.  It never really overtook either Cobol or
> Fortran in popularity, despite a few admirers, and remains a
> good object lesson in complicated languages and their
> failure-mechanisms.

<hack>long and lucid dissention with my position</hack>

I've been there, Alex.  PL/1 was my third language, and I wrote a great many
lines of REXX on the IBM 370.  I even have Regina (the Unix REXX clone)
installed
on my Linux desktop.

The fact is, it really just requires that reserved words which would
otherwise
raise a SyntaxError should be rechecked as identifiers.  The code to do it
shouldn't be long or slow.  I admit that my cursory study of the parser code
left me a bit lost as to how such a change would be made, but I haven't
written
language parser code in ten years.  I worked on several limited-purpose
languages
in the past, but never had the time to do anything like Python myself... I
don't
know if I have that much talent, anyway.  I *do* know, from writing an infix
expression parser, that recognizing reserved words in the role of
identifiers
is doable and not expensive at that.

I still use that parser in C projects BTW, and it uses it's own stack on the
heap
instead of wasting stack space as many others do.  (I wrote it that way for
DOS
Compact mode executables; no more than 64K code, but 64K stack + "unlimited"
far
heap).

In another post Tim Peters says that Guido agrees with me on this; I'm
flattered,
although according to the same post Guido requested a patch to do just this
and
so far no one has offered one.

Does anyone know of a "roadmap" to the Python parser internals?