Message364112
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. |
|
Date |
User |
Action |
Args |
2020-03-13 17:08:02 | zd nex | set | recipients:
+ zd nex |
2020-03-13 17:08:02 | zd nex | set | messageid: <1584119282.92.0.936171127004.issue39956@roundup.psfhosted.org> |
2020-03-13 17:08:02 | zd nex | link | issue39956 messages |
2020-03-13 17:08:02 | zd nex | create | |
|