Nick Coghlan <ncogh...@gmail.com> added the comment:
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):
```
>>> dis.dis("+1")
1 0 LOAD_CONST 1 (1)
2 RETURN_VALUE
>>> dis.dis("-1")
1 0 LOAD_CONST 1 (-1)
2 RETURN_VALUE
>>> dis.dis("1+1")
1 0 LOAD_CONST 1 (2)
2 RETURN_VALUE
>>> dis.dis("1+1j")
1 0 LOAD_CONST 2 ((1+1j))
2 RETURN_VALUE
>>> dis.dis("2017-10-10")
1 0 LOAD_CONST 3 (1997)
2 RETURN_VALUE
```
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:
```
>>> type(ast.parse("2+3").body[0].value) is ast.BinOp
True
>>> type(ast.parse("2017-10-10").body[0].value) is ast.BinOp
True
```
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.
----------
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 3.6
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31778>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
