[Python-bugs-list] [ python-Bugs-796116 ] Parser wart

[SourceForge.net]

Bugs item #796116, was opened at 2003-08-27 12:26
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796116&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
>Priority: 2
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Jeremy Hylton (jhylton)
Summary: Parser wart

Initial Comment:
Its okay that the parser allows 10+2 to be correctly 
interpreted, but keywords should require whitespace 
separation.  Currently, intervening whitespace is not 
required:

>>> 10and 1
1




----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-08-29 03:29

Message:
Logged In: YES 
user_id=539787

History: this wart (keywords legally appended to numeric 
constants, which keywords don't start with 'e', 'f', and 'd' 
perhaps) appears in all languages I have used in my life (well, 
except for the ZX Spectrum 48K Basic, where eg. the 1.5 
keypress for 'and' produced ' and ' forcefully :)

The easiest way would be to have a significant_whitespace 
node in Grammar/Grammar, which would be inserted just 
before the 'and' and 'or' keywords in and_test and or_test, 
but Grammar does not deal with whitespace.  Let's look 
parsemodule.c... could one SIG_WHITESPACE token be 
produced?  Also, what about line continuations having 'and' 
or 'or' in the beginning of a physical line?

I believe this wart should be eliminated only if letter suffixes 
are allowed to numeric constants, which I doubt will happen; 
I'd suggest to lower the priority of this unless somebody finds 
a quick-n-dirty solution.  Not that important.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796116&group_id=5470