Message312687
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? |
|
Date |
User |
Action |
Args |
2018-02-24 02:04:23 | terry.reedy | set | recipients:
+ terry.reedy, rhettinger, benjamin.peterson, serhiy.storchaka |
2018-02-24 02:04:23 | terry.reedy | set | messageid: <1519437863.35.0.467229070634.issue32893@psf.upfronthosting.co.za> |
2018-02-24 02:04:23 | terry.reedy | link | issue32893 messages |
2018-02-24 02:04:22 | terry.reedy | create | |
|