Long names are doom ?

[Thomas Wouters]

On Sun, May 27, 2001 at 05:41:08PM -0400, Tim Peters wrote:
> [Thomas Wouters]
> > There are basically two choices wrt. allowing reserved words as
> > vrbl names:

> > 1) allow them everywhere, in any situation. ...
> > ...
> > 2) Allow them in certain locations only, like calling functions
> > with keyword arguments, attribute-referencing/assignment and 'def'
> > statements inside classes (but not outside.) ...
> > ...
> > Guido agreed with #2 already (pending implementation). I'm
> > not sure what his opinion of #1 is,

> I'll channel him, then:  no way.

Pity, but understandble. I have to admit that the 'other parsers' argument
has been nagging in the back of my mind every time the subject of a more
advanced parser comes up.

> As a first cut, you might, e.g., try replacing

> dotted_name: NAME ('.' NAME)*

> with

> dotted_name: NAME ('.' anyname)*
> anyname: NAME | 'and' | 'assert' | 'break' | ... | 'while'

Been there, done that. It's somewhere in the python-dev archives, *I
believe* right before 2.0 was released (but I'm not sure.) One of the few
threads that all of Mark, Guido and me posted, if that's any help in
searching ;)

> Then see what breaks and fix it <wink>.

Unfortunately, doing it that way breaks a whole lot. Almost every place in
compile.c that handles NAME's just does a 'STR(n)', and tracking them is a
serious pain in the tooshie. I went the even-easier-way <wink>, and replaced
e.g.

dotted_name: NAME ('.' NAME)*

with

dotted_name: NAME ('.' NAME | 'and' | 'assert' | 'break' | ... | 'while')*

That worked fine, for the limited testing I did with it. That's why my
earlier posting talked about a pre-processor. Or did it ? Maybe that posting
was stillborn -- I'm tired, I might have taken the easy way out :)

If-only-the-ellipsis-in-the-keyword-list-actually-worked-ly y'rs,
-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!