Usage of ast.

[Jon Ribbens]

On 2017-02-27, Chris Angelico <rosuav at gmail.com> wrote:
> On Tue, Feb 28, 2017 at 1:18 AM, Jon Ribbens <jon+usenet at unequivocal.eu> wrote:
>> "execution" isn't really the right way to describe literal_eval().
>> It isn't an code executor or even an expression evaluator, all it
>> does is turns a Python literal in source form into the value that
>> source represents. You can't do literal_eval("2*3") for example,
>> because that's an expression not a literal.
>>
>> The only reason you can do literal_eval("2+3") (in Python>=3.2)
>> is because of a side effect of the fact that complex number literals
>> are, well, complex ("2+3j"), and the support for +/- wasn't restricted
>> to complex literals only.
>
> Actually it does execute, as you can see from the source code.

I'm not sure what you mean by that. I was looking at the source code
(and its history) when I wrote my post, and I would be hard pushed to
describe it as "executing" anything.

> The name "literal" is slightly incorrect technically, as it will run
> some code that isn't actually a literal (nor even covered by constant
> folding, which "2+3j" is - it's two literals and a binary operator,
> but constant folded at compile time).

Actually the name is more correct than the code is! It is clear that
what it is trying to do is exactly as I described above and as its
name indicates. The fact that in Python >= 3.2 it allows binary
addition and subtraction of numeric values is an undocumented
extension to the specification resulting from a side effect of the
implementation.

>>>> ast.literal_eval("[1,2,3]")
> [1, 2, 3]
>
> This isn't a literal, and it's evaluated by literal_eval.

Actually, that is a literal, in the computer science sense: "a literal
is a notation for representing a fixed value in source code".
I realise it isn't a literal in the sense of "as defined by section
2.4 of the Python Language Reference", but then perhaps most people
would expect the word to have its more generic meaning.

Python doesn't seem to have a word for "[1, 2, 3]", inasmuch as
it is an example of a "list display", but that form is only a subset
of what "list display" means (displays include comprehensions), so
it is not true to say that literal_eval() can evaluate displays.
If we had to choose a way to describe it, it seems unlikely that
there's a better description than "list literal".

(See also the "What's new" announcement for Python 3.2 where the
addition of set support to literal_eval() was described as adding
"set literals". https://docs.python.org/3/whatsnew/3.2.html#ast )

> It's basically a "safe eval of simple expressions".

What I was trying to say was that I think that is a very misleading
way of describing it. It is not entirely untrue, but it is much closer
to being false than it is to being true. It isn't "safe eval", and it
is not intended to deal with any expressions.

(See also http://bugs.python.org/issue22525 )