This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author zd nex
Recipients zd nex
Date 2020-03-13.17:08:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1584119282.92.0.936171127004.issue39956@roundup.psfhosted.org>
In-reply-to
Content
So currently if python code contains 1_1 it is handled as number 11. When user uses int("1_1") it also creates 11 and when ast.literal_eval is used it is also created instead of string. How can user get SyntaxError input on int or literal_eval with obviously wrong input (some keyboards have . next to _) like int(input()) in REPL? In python2.7 this was checked, but now even string is handled as number. Is there some reason? 

I understand reasoning behind PEP515, that int(1_1) can create 11, but why int("1_1") creates it also? Previously users used literal_eval for safe check of values, but now user can put 1_1 and it is transferred as number. Is there some plan to be able control behavior of these functions? I was now with some students, which used python2.7 and they find it also confusing. Most funny thing is that when they do same thing in JavaScript parseInt("1_1") they get 1, in old python this was error and now we give them 11. 

I would suggest that it would be possible to strictly check strings, as it was in old Python2.7. This way user would be able to use _ in code to arrange numbers, but it would also allow checks on wrong inputs of users which were meant something else, for example if you use it in try/except in console.
History
Date User Action Args
2020-03-13 17:08:02zd nexsetrecipients: + zd nex
2020-03-13 17:08:02zd nexsetmessageid: <1584119282.92.0.936171127004.issue39956@roundup.psfhosted.org>
2020-03-13 17:08:02zd nexlinkissue39956 messages
2020-03-13 17:08:02zd nexcreate