Long names are doom ?

[Tim Peters]

[Thomas Wouters]
> ...
> 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.

Indeed, if stupid regexp tricks aren't enough to deduce the "big picture"
reliably, we can toss at least PythonWin's, IDLE's, and the Emacs pymode's
toy parsers out the window.

>> 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 ;)

If I had bandwidth for that, I'd just do it <0.5 wink>.

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

> Unfortunately, doing it that way breaks a whole lot.

Doing what?  Changing *just* dotted_name, or the more ambitious "allow
everything everywere" bit?

> 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.

There are 51 of those.  Do 10 a day and you'll be done in 6 weeks <wink>.

> 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?

Don't recall it.  Perhaps it was too painful to talk about, though.

> ...
> If-only-the-ellipsis-in-the-keyword-list-actually-worked-ly y'rs,

import keyword
ellipsis = " | ".join(map(repr, keyword.kwlist))

Some things are just easier in Python <ahem>.  A preprocessor would be a
more expedient hack, but the pain in doing it the original & cleaner way
looks finite.