[ python-Bugs-796116 ] Parser wart
SourceForge.net
noreply at sourceforge.net
Sun Jul 11 02:05:15 CEST 2004
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: Closed
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
More information about the Python-bugs-list
mailing list