On 2017-02-27, Chris Angelico <ros...@gmail.com> wrote: > On Tue, Feb 28, 2017 at 1:18 AM, Jon Ribbens <jon+use...@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 ) -- https://mail.python.org/mailman/listinfo/python-list