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 

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>
Python-bugs-list mailing list

Reply via email to