Terry J. Reedy <tjre...@udel.edu> added the comment:
Whoops, my previous response was wrong as written because I wrongly thought
that if literal_eval accepts number_literal + imaginary_literal, it would also
accept number_literal + number_literal. I am replacing it with the following.
The ast.literal_eval doc says
"The string or node provided may only consist of the following Python literal
structures: strings, bytes, numbers, tuples, lists, dicts, sets, booleans, and
None."
Since 'True', '(True,)', '[True]', '{True:True}', '+1', '-1' and '1+1j' are
accepted as 'literal structures', it seems arbitrary that at least '+True' and
'True+1j' are not. ('+1', '1+1j' and especially '-1' seem to violate the
limitations to 'literal', 'container', and 'no operator', but that is a
different issue.)
I strongly agree that the acceptable string inputs and acceptable AST inputs
should match. The question is which version of the domain should be changed.
I would at least mildly prefer that the issue be "ast.literal_eval should
consistly treat False and True the same as 0 and 1.", which means expanding the
string version. As Raymond said, this is the general rule in Python. What is
the benefit of having a different rule for this one function?
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32893>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
