New submission from zd nex <zdnex...@gmail.com>:
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.
----------
messages: 364112
nosy: zd nex
priority: normal
severity: normal
status: open
title: Numeric Literals vs string "1_1" on input int() or float() or
literal_eval
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue39956>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
