Initially I thought this was related to PEP-515 but the unexpected behavior extends to simpler examples as well, such as:
>>> x =5
>>> 123or x
123
>>> 123and x
5
I'm not familiar enough with C to understand why this is being parsed/tokenized this way, but this seems like it should instead be a SyntaxError. This appears to be fairly old behavior, as the non-underscored version works back to at least 2.7.
Sorry, the bonus, while fun, I don't think is related
alimuldal commented on Apr 13, 2021
alimuldalmannequin
Mannequin
More actions
Several other keywords seem to be affected, including if, else, is, and in
cfbolz commented on Apr 13, 2021
cfbolzmannequin
Mannequin
More actions
It's not just about keywords. Eg '1x' tokenizes too but then produces a syntax error in the parser. Keywords are only special in that they can be used to write syntactically meaningful things with these concatenated numbers.
I would like to note that syntax like this is in heavy use in the Code Golf community (a sport in which the aim is to write the shortest code possible to complete a particular task).
I could understand if this change remains because code golf is not exactly an important thing with serious ramifications, but I think it should be taken in to consideration as a use-case nonetheless.
Reacted by FichteFoll, Abbas Yadollahi and Marek Madejski
I tried the code that is the subject of this issue,
[0x1forxinrange(10)]
but in the usual IDLE installable from python.org, it doesn't raise anything. It still returns [31].
Further note to @pxeger: Our code-golf answers are normally posted in a specific python version (such as 2 or 3). When it's omitted, we assume it's Python 3, or the Python version that existed when the answer was posted. Besides an easy fix for this issue will be to specify the latest version of Python that allows this bug to be exploited, i.e. if this bug is fixed in, say Python 3.12, we can simply update our answers to say they work in Python versions before 3.12. Otherwise I don't think this bug being fixed will result in issues in executed code.
Activity
sco1 commented on Apr 13, 2021
Came across this riddle today:
Initially I thought this was related to PEP-515 but the unexpected behavior extends to simpler examples as well, such as:
I'm not familiar enough with C to understand why this is being parsed/tokenized this way, but this seems like it should instead be a SyntaxError. This appears to be fairly old behavior, as the non-underscored version works back to at least 2.7.
And a bonus:
sco1 commented on Apr 13, 2021
Sorry, the bonus, while fun, I don't think is related
alimuldal commented on Apr 13, 2021
Several other keywords seem to be affected, including if, else, is, and in
cfbolz commented on Apr 13, 2021
It's not just about keywords. Eg '1x' tokenizes too but then produces a syntax error in the parser. Keywords are only special in that they can be used to write syntactically meaningful things with these concatenated numbers.
pablogsal commented on Apr 13, 2021
This is know behaviour unfortunately and cannot be changed because of backwards compatibility.
26 remaining items
miss-islington commented on Jun 8, 2021
New changeset eeefa7f by Miss Islington (bot) in branch '3.10':
bpo-43833: Emit warnings for numeric literals followed by keyword (GH-25466)
eeefa7f
pxeger commented on Jun 24, 2021
I would like to note that syntax like this is in heavy use in the Code Golf community (a sport in which the aim is to write the shortest code possible to complete a particular task).
It will be disappointing if it becomes an error and break many past programs (you can search for phrases like 1and, 0for on https://codegolf.stackexchange.com/search?q=0for for examples).
I could understand if this change remains because code golf is not exactly an important thing with serious ramifications, but I think it should be taken in to consideration as a use-case nonetheless.
gvanrossum commented on Nov 8, 2021
Do we have a plan for when this will be turned into a non-silent warning and when into an error?
pablogsal commented on Nov 8, 2021
Unless I am missing something it should be 3.11 non-silent warning and 3.12 syntax error
gvanrossum commented on Apr 25, 2022
Following up: Is this a non-silent warning yet?
serhiy-storchaka commented on Apr 25, 2022
It is still DeprecationWarning.
pythongh-87999: Change warning type for numeric literal followed by k…
gh-87999: Change warning type for numeric literal followed by keyword (…
Rhaxier commented on Nov 17, 2022
I tried the code that is the subject of this issue,
but in the usual IDLE installable from python.org, it doesn't raise anything. It still returns [31].
Further note to @pxeger: Our code-golf answers are normally posted in a specific python version (such as 2 or 3). When it's omitted, we assume it's Python 3, or the Python version that existed when the answer was posted. Besides an easy fix for this issue will be to specify the latest version of Python that allows this bug to be exploited, i.e. if this bug is fixed in, say Python 3.12, we can simply update our answers to say they work in Python versions before 3.12. Otherwise I don't think this bug being fixed will result in issues in executed code.
serhiy-storchaka commented on Nov 17, 2022
Please open a new issue for IDLE. Perhaps there is already an open issue for SyntaxWarning in IDLE.
Rhaxier commented on Nov 18, 2022
I have opened a new one under BPO 99567.
Rhaxier commented on Dec 5, 2022
@pablogsal this comment on my closed issue says otherwise: