Usage of ast.

[Jon Ribbens]

On 2017-02-27, Chris Angelico <rosuav at gmail.com> wrote:
> On Tue, Feb 28, 2017 at 3:58 AM, Jon Ribbens <jon+usenet at unequivocal.eu> wrote:
>> Seeing as most of it is code along the lines of "is this an integer
>> constant? if so the value is that constant": no, I think "execution"
>> is a misleading word to use.
>
> That's true of a lot of executors. Doesn't change the fact that it
> will look at a UnaryOp or BinOp and (if it's [U]Add or [U]Sub) perform
> the corresponding operation. That's execution.

Yes. I didn't say the word "executing" was strictly false, just that
it is misleading, which it is.

>> So it isn't a literal "by my definition" after all (which isn't "my"
>> definition by the way).
>
> It's completely acceptable to ast.literal_eval.

Sorry, I must have missed something here. What are you talking about?
"lambda: [1,2,3]" is not acceptable input to ast.literal_eval(), it
will throw an exception.

>>> There's no literal syntax "frozenset({1, 2, 3})", but that got loaded
>>> as a constant.
>>
>> So that isn't a literal either - and it isn't accepted by literal_eval.
>> Jolly good. What's the problem?
>
> According to the disassembly (see my original post), it can be a
> constant. Not even a literal, yet it's a constant that gets baked into
> the function's attributes.

It's not a literal, and literal_eval() doesn't accept it.
A conundrum for the ages indeed.

>>>> 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".
>>>
>>> It's a list display.
>>
>> I just explained right there in the text you quoted why that is not
>> sufficient as a description. Just repeating part of what I already
>> said back to me and ignoring the rest isn't going to progress things
>> very much.
>
> My point is that it truly IS a list display, despite your concerns.

Yes. As I already said that I already said, I already said that.
As I also already said, please stop repeating me back to me.

>>> That's a pretty tricky concept to try to bake into a definition, but
>>> that's exactly the recursive definition that literal_eval actually uses.
>>
>> So the definition is useful and accurate then!
>
> Yet it disagrees with the comp sci definition that you espoused earlier.

In what way?

> Nope. I still believe that literal_eval isn't precisely evaluating
> literals in the Python sense,

Yes, that is also what I already said. It's evaluating literals in the
comp sci sense (with an undocumented extension in some versions that
should not be relied on as it's a side effect of the implementation).

> but that it evaluates a subset of expressions that can be safely
> parsed.

Yes, but as I already said it is such a tiny subset of expressions
that even comparing it to that set is utterly misleading. It's like
calling the number 7 "a subset of the real numbers". It's technically
true ("the best kind of true!") but leads you in completely the wrong
direction.

>>> Its docstring most definitely says "expression", though, because
>>> there are some non-literal expressions that it DOES evaluate, and
>>> for good reason.
>>
>> ... the good reason being that they are literals.
>
> Yeah, but we haven't settled a definition that actually means that they are.

I'm getting a bizarre sense of deja vu in pointing out that I'm
repeating myself, but: "a literal is a notation for representing
a fixed value in source code".