Steve Dower added the comment:
FTR, I think this was a bad fix and we should have just changed the spec to
require a space between numeric literals and identifiers.
Closing as by design would have been fine in my opinion as well, since the spec
says spaces are required when it's ambiguous,
R. David Murray added the comment:
My impression is that it was fixed the way it was because it makes the internal
tokenizer match the what the tokenize module does. See also issue 3353. As
for changing it in a point release, it turns something that was an error into
something that isn't,
Roundup Robot added the comment:
New changeset 4ad33d82193d by Benjamin Peterson in branch '3.4':
allow the keyword else immediately after (no space) an integer (closes #21642)
http://hg.python.org/cpython/rev/4ad33d82193d
New changeset 29d34f4f8900 by Benjamin Peterson in branch '2.7':
allow
Joshua Landau added the comment:
Here's a minimal example of the difference:
1e
# ... etc ...
# SyntaxError: invalid token
1t
# ... etc ...
# SyntaxError: invalid syntax
--
___
Python tracker rep...@bugs.python.org
New submission from Joshua Landau:
By the docs,
Except at the beginning of a logical line or in
string literals, the whitespace characters space,
tab and formfeed can be used interchangeably to
separate tokens. Whitespace is needed between two
tokens only if their
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21642
___
___
Changes by wim glenn wim.gl...@gmail.com:
--
nosy: +wim.glenn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21642
___
___
Python-bugs-list mailing
Martin v. Löwis added the comment:
For those who want to skip reading the entire SO question: 1else tokenizes as
1e lse, i.e. 1e is considered the beginning of floating point literal. By
the description in the docs, that should not happen, since it is not a valid
literal on its own, so no
