[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Pablo Galindo Salgado added the comment: Unless I am missing something it should be 3.11 non-silent warning and 3.12 syntax error -- ___ Python tracker ___

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Guido van Rossum added the comment: Do we have a plan for when this will be turned into a non-silent warning and when into an error? -- ___ Python tracker ___

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Patrick Reader added the comment: 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

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

miss-islington added the comment: New changeset eeefa7f6c0cc64bc74c3b96a0ebbff1a2b9d3199 by Miss Islington (bot) in branch '3.10': bpo-43833: Emit warnings for numeric literals followed by keyword (GH-25466) https://github.com/python/cpython/commit/eeefa7f6c0cc64bc74c3b96a0ebbff1a2b9d3199

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Change by miss-islington : -- pull_requests: +25198 pull_request: https://github.com/python/cpython/pull/26614 ___ Python tracker ___

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

miss-islington added the comment: New changeset 2ea6d890281c415e0a2f00e63526e592da8ce3d9 by Serhiy Storchaka in branch 'main': bpo-43833: Emit warnings for numeric literals followed by keyword (GH-25466) https://github.com/python/cpython/commit/2ea6d890281c415e0a2f00e63526e592da8ce3d9

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Guido van Rossum added the comment: Actually I believe a real case was reported on python-dev. I think it is not clean that the boundary between numbers and identifiers is so fluid. -- nosy: +Guido.van.Rossum ___ Python tracker

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Raymond Hettinger added the comment: I recommend just letting this be. Aside from it allowing for a cute riddle, in the real world seems to be harmless and not worth breaking code. There are lots of other harmless oddities such as the space-invader increment operator: x -=- 1 FWIW, a

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

sco1 added the comment: Makes sense, thanks! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Serhiy Storchaka added the comment: There is no issues with lists and strings. "]" clearly ends the list display, and a quote ends a string literal. The problem with numeric literals is that they can contain letters, so it is not clear (for human reader) where the numeric literals ends and

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

sco1 added the comment: We can also see this kind of thing with other literals, would that be in scope here? e.g. ``` Python 3.9.4 (default, Apr 5 2021, 12:33:45) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Serhiy Storchaka added the comment: PR 25466 makes the tokenizer emitting a deprecation warning if the numeric literal is followed by one of keywords which are valid after numeric literals. In future releases it will be changed to syntax warning, and finally to syntax error. It is breaking

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +24190 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25466 ___ Python tracker

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Shreyan Avigyan added the comment: @Carl.Friedrich.Bolz Thanks a lot for clarifying. For a second, I thought it was maybe a bug. -- ___ Python tracker ___

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Carl Friedrich Bolz-Tereick added the comment: @shreyanavigyan This is a bit off-topic, but it's called "short-circuiting", described here: https://docs.python.org/3/library/stdtypes.html#boolean-operations-and-or-not (or/and aren't really "operators", like +/- etc, they cannot be

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Shreyan Avigyan added the comment: Hi. I just want to know why is and, or operators behaving like this. The behavior is described in https://bugs.python.org/issue43833#msg390996. Moreover I researched a little more and found out even if __and__, __or__ methods are defined the and, or

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Pablo Galindo Salgado added the comment: One thing we could consider as Serhiy proposed on the mailing list is to emit a Syntax Warning. The ambiguous cases are specially scary so I think that makes sense -- ___ Python tracker

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Anthony Sottile added the comment: here's quite a few other cases as well -- I'd love for this to be clarified in PEP8 such that I can rationalize crafting a rule for it in `pycodestyle` -- https://github.com/PyCQA/pycodestyle/issues/371 -- nosy: +Anthony Sottile

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

sco1 added the comment: Appreciate the additional historical context, I also was pointed to this in the documentation: https://docs.python.org/3/reference/lexical_analysis.html#whitespace-between-tokens If a parsing change is undesired from a backwards compatibility standpoint, would it be

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Pablo Galindo Salgado added the comment: Precisely because examples like that changing this is a breaking change. Don't get me wrong: I would love to change it, but I don't know if is worth the risk -- ___ Python tracker

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Serhiy Storchaka added the comment: Better example: >>> [0x1for x in (1,2)] [31] The code is parsed as [0x1f or x in (1,2)] instead of [0x1 for x in (1,2)] as you may expect. -- ___ Python tracker

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Pablo Galindo Salgado added the comment: We tried changing this IIRC and it broke code in the stdlib (now reformatted) so it will break code in the wild. I am not sure the gains are worth it. -- ___ Python tracker

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Shreyan Avigyan added the comment: Hi. I'm totally confused about other keywords but I'm a little concerned about the "and", "or" operator when used on, not only "int" (also known as "long") but also most Python objects other then bool type. Mostly when used on Python built-in objects

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Serhiy Storchaka added the comment: Good example! Similar issue was discussed on the mailing list 3 years ago (https://mail.python.org/archives/list/python-...@python.org/thread/D2WPCITHG2LBQAP7DBTC6CY26WQUBAKP/#D2WPCITHG2LBQAP7DBTC6CY26WQUBAKP). Now with new example it perhaps should be

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Pablo Galindo Salgado added the comment: This is know behaviour unfortunately and cannot be changed because of backwards compatibility. -- nosy: +pablogsal ___ Python tracker

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Carl Friedrich Bolz-Tereick added the comment: 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. -- nosy:

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Alistair Muldal added the comment: Several other keywords seem to be affected, including `if`, `else`, `is`, and `in` -- nosy: +alimuldal ___ Python tracker ___

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

sco1 added the comment: Sorry, the bonus, while fun, I don't think is related -- ___ Python tracker ___ ___ Python-bugs-list

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Change by Rich rauenzahn : -- nosy: +rrauenza ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

Change by Ned Batchelder : -- nosy: +nedbat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators

New submission from sco1 : Came across this riddle today: >>> [0x_for x in (1, 2, 3)] [15] 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