I afraid this makes an error message more confusing and misleading.
>>> ast.literal_eval('~2')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/serhiy/py/cpython/Lib/ast.py", line 93, in literal_eval
return _convert(node_or_string)
File "/home/serhiy/py/cpython/Lib/ast.py", line 92, in _convert
return _convert_signed_num(node)
File "/home/serhiy/py/cpython/Lib/ast.py", line 65, in _convert_signed_num
return _convert_num(node)
File "/home/serhiy/py/cpython/Lib/ast.py", line 56, in _convert_num
raise ValueError('%s not allowed in literal' % type(node).__name__)
ValueError: UnaryOp not allowed in literal
This is not true since + and - are allowed:
>>> ast.literal_eval('-2')
-2
>>> ast.literal_eval('2+3')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/serhiy/py/cpython/Lib/ast.py", line 93, in literal_eval
return _convert(node_or_string)
File "/home/serhiy/py/cpython/Lib/ast.py", line 92, in _convert
return _convert_signed_num(node)
File "/home/serhiy/py/cpython/Lib/ast.py", line 65, in _convert_signed_num
return _convert_num(node)
File "/home/serhiy/py/cpython/Lib/ast.py", line 56, in _convert_num
raise ValueError('%s not allowed in literal' % type(node).__name__)
ValueError: BinOp not allowed in literal
But:
>>> ast.literal_eval('2+3j')
(2+3j)
>>> ast.literal_eval('"a"+"b"')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/serhiy/py/cpython/Lib/ast.py", line 93, in literal_eval
return _convert(node_or_string)
File "/home/serhiy/py/cpython/Lib/ast.py", line 85, in _convert
left = _convert_signed_num(node.left)
File "/home/serhiy/py/cpython/Lib/ast.py", line 65, in _convert_signed_num
return _convert_num(node)
File "/home/serhiy/py/cpython/Lib/ast.py", line 56, in _convert_num
raise ValueError('%s not allowed in literal' % type(node).__name__)
ValueError: Str not allowed in literal
Hmm, I think I see what I broke there. It was part of the merge conflict resolution - I moved the check into the function, which is actually incorrect. It wasn't misleading like that in the original patch. Will fix that.
Actually, it's a bit more complicated than I thought. Current proposed solution: Track the context of each conversion, thus allowing different errors to be distinguished.
Activity
Rosuav commented on Feb 20, 2018
When a non-literal is given to literal_eval, attempt to be more
helpful with the message, rather than calling it 'malformed'.
serhiy-storchaka commented on Feb 20, 2018
I afraid this makes an error message more confusing and misleading.
>>> ast.literal_eval('~2') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/serhiy/py/cpython/Lib/ast.py", line 93, in literal_eval return _convert(node_or_string) File "/home/serhiy/py/cpython/Lib/ast.py", line 92, in _convert return _convert_signed_num(node) File "/home/serhiy/py/cpython/Lib/ast.py", line 65, in _convert_signed_num return _convert_num(node) File "/home/serhiy/py/cpython/Lib/ast.py", line 56, in _convert_num raise ValueError('%s not allowed in literal' % type(node).__name__) ValueError: UnaryOp not allowed in literalThis is not true since + and - are allowed:
But:
But Str is allowed:
>>> ast.literal_eval('"ab"') 'ab'Rosuav commented on Feb 20, 2018
Hmm, I think I see what I broke there. It was part of the merge conflict resolution - I moved the check into the function, which is actually incorrect. It wasn't misleading like that in the original patch. Will fix that.
Rosuav commented on Feb 20, 2018
Actually, it's a bit more complicated than I thought. Current proposed solution: Track the context of each conversion, thus allowing different errors to be distinguished.
Rosuav commented on Feb 20, 2018
(BTW, by "proposed" I mean that the change that I describe is in the PR.)
serhiy-storchaka commented on Jul 3, 2018
Please wait until bpo-32892 and bpo-32893 be committed or rejected before merging this PR.