ast.literal_eval supports non-literals in Python 3 #75959
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee = None closed_at = <Date 2018-01-04.09:27:28.780> created_at = <Date 2017-10-12.22:31:18.436> labels = ['type-feature', '3.7', 'docs'] title = 'ast.literal_eval supports non-literals in Python 3' updated_at = <Date 2018-01-04.09:27:28.779> user = 'https://bugs.python.org/DavidBieber'
activity = <Date 2018-01-04.09:27:28.779> actor = 'serhiy.storchaka' assignee = 'docs@python' closed = True closed_date = <Date 2018-01-04.09:27:28.780> closer = 'serhiy.storchaka' components = ['Documentation'] creation = <Date 2017-10-12.22:31:18.436> creator = 'David Bieber' dependencies =  files =  hgrepos =  issue_num = 31778 keywords = ['patch'] message_count = 11.0 messages = ['304294', '304367', '304374', '304379', '304400', '304573', '304574', '304580', '305973', '305987', '309460'] nosy_count = 10.0 nosy_names = ['brett.cannon', 'nascheme', 'rhettinger', 'terry.reedy', 'ncoghlan', 'benjamin.peterson', 'r.david.murray', 'docs@python', 'serhiy.storchaka', 'David Bieber'] pr_nums = ['4035'] priority = 'normal' resolution = 'fixed' stage = 'resolved' status = 'closed' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue31778' versions = ['Python 3.7']
The text was updated successfully, but these errors were encountered:
# The Issue
However, literal_eval is capable of evaluating expressions with certain operators, particular the operators "+" and "-".
As has been explained previously, the reason for this is to support "complex" literals such as 2+3j. However, this has unintended consequences which I believe to be indicative of a bug. Examples of the unintended consequences include
Since issue arose as a Python Fire issue, where the behavior of Python Fire was unexpected for inputs such as those described above (1+1 and 2017-10-10) only in Python 3. For context, Python Fire is a CLI library which uses literal_eval as part of its command line argument parsing procedure.
I think the resolution to this issue is having literal_eval raise a ValueError if the ast of the input represents anything other than a Python literal, as described in the documentation. That is, "The string or node provided may only consist of the following Python literal structures: strings, bytes, numbers, tuples, lists, dicts, sets, booleans, and None." Additional operations, such as the binary operations "+" and "-", unless they explicitly create a complex number, should produce a ValueError.
If that resolution is not the direction we take, I also would appreciate knowing if there is another built in approach for determining if a string or ast node represents a literal.
import ast ast.literal_eval('1+1')
import ast ast.literal_eval('2017-10-10')
It has been some time since literal_eval literally only evaluated literals. 'constant_eval' might be a better name now, with the proviso of 'safely, in reasonable time'.
>>> from ast import literal_eval as le >>> le('(1,2,3)') (1, 2, 3) >>> le('(1,2, (3,4))') (1, 2, (3, 4))
I believe there was once a time when a simple tuple would be evaluated, while a nested one would not be.
"It is not capable of evaluating arbitrarily complex expressions, for example involving operators or indexing." I do not read this as prohibiting all operators, but rather that now all will be accepted.
>>> le(2**2) ... ValueError: malformed node or string: 4
Exponentiation of ints can take exponential time and can be used for denial of service attacks.
>>> le('2017-10-10') 1997
This is correct. For '2017-10-10' to be a string representing a date, it must be quoted as a string in the code.
>>> le("'2017-10-10'") '2017-10-10'
Rolling back previous enhancements would break existing code, so a deprecation period would be required. But I would be inclined to instead update the doc to match the updated code better. Lets see what others think.
I'm marking this as documentation issue for now, as the operators that literal_eval allows are solely those where constant folding support is needed to correctly handle complex and negative numbers (as noted in the original post):
So the key promise that literal_eval makes is that it will not permit arbitrary code execution, but the docs should make it clearer that it *does* permit constant folding for addition and subtraction in order to handle the full range of numeric literals.
If folks want to ensure that the input string *doesn't* include a binary operator, then that currently needs to be checked separately with ast.parse:
For 3.7+, that check could potentially be encapsulated as an "allow_folding=True" keyword-only parameter (where the default gives the current behaviour, while "allow_folding=False" disables processing of UnaryOp and BinOp), but the docs update is the more immediate need.
I sympathize completely with the need to maintain backward compatibility. And if this is the reason that this issue gets treated only as a documentation issue, rather than as a behavior issue, I can appreciate that.
If that is the case and literal_eval is not going to only evaluate literals, then for my use case I'll need a way to determine from a string whether it represents a literal. I can implement this myself using ast.parse and walking the resulting tree, looking for non-literal AST nodes. Would such an "is_literal" function would be more appropriate in the ast module than as a one-off function in Python Fire?
I disagree that this is the only key promise, and here's my reasoning. The docstring has two sentences, and each one makes a promise:
# Additional observations
In my opinion, Python 2's behavior is correct in these situations since it matches the documentation and only evals literals as defined in the documentation.
Thanks for your replies and for hearing me out on this issue.
1+1 is not a literal number.
Just a comment on what I guess is the intended use of literal_eval(), i.e. taking a potentially untrusted string and turning it into a Python object. Exposing the whole of the Python parser to potential attackers would make me very worried. Parsing code for all of Python syntax is just going to be very complicated and there can easily be bugs there. Generating an AST and then walking over it to see if it is safe is also scary. The "attack surface" is too large. This is similar to the Shellshock bug. If you can trust the supplier of the string then okay but I would guess that literal_eval() is going to get used for untrusted inputs.
It would be really nice to have something like ast.literal_eval() that could be used for untrusted strings. I would implement it by writing a retricted parser. Keep it extremely simple. Validate it by heavy code reviews and extensive testing (e.g. fuzzing).