Usage of ast.

[Chris Angelico]

On Tue, Feb 28, 2017 at 3:58 AM, Jon Ribbens <jon+usenet at unequivocal.eu> wrote:
> On 2017-02-27, Chris Angelico <rosuav at gmail.com> wrote:
>> On Tue, Feb 28, 2017 at 3:17 AM, Jon Ribbens <jon+usenet at unequivocal.eu> wrote:
>>> On 2017-02-27, Chris Angelico <rosuav at gmail.com> wrote:
>>>> 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.
>>
>> You could say that it "interprets" the AST. It has exactly the same
>> kind of if/elif tree of "this kind of thing? do this" that a naive and
>> unoptimized language interpreter would use. Does that not count as
>> execution?
>
> 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.

>>> 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.
>>
>> So what _is_ a literal?
>
> It's "a notation for representing a fixed value in source code",
> I just said so right there above.
>
>> Can you have a literal that evaluates to a non-constant, or a
>> non-literal that gets compiled to a constant? Here are examples of both:
>>
>>>>> dis.dis(lambda: [1,2,3])
>
>> By your definition, this is a literal,
>
> No, it isn't - it's pushing it somewhat to call a function a "value"
> (especially in the context of when words like "literal" were coined),
> and it's certainly not a "fixed value" in this sense. (Yes, I know the
> function itself does not change. That doesn't make it a "fixed value".)
>
>> but it most surely does not represent a fixed value.
>
> 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. You said earlier that
literal_eval really does evaluate literals, not expressions. So how
can this simultaneously be acceptable to literal_eval but not a
literal, of literal_eval evaluates literals? (Woodchucks chucking wood
come to mind.)

>> 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.

>>> 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.
"42" is a subset of the definition of integer literals, but that
doesn't stop it from being one.

>> 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.

>> Given the many subtle differences in usage of the word "literal", I'm
>> happy with it using that name. It's not 100% accurate, but it covers
>> the non-pedantic uses of the term.
>
> You seem to have got turned around and are now arguing in favour of my
> position and against your own previous position.

Nope. I still believe that literal_eval isn't precisely evaluating
literals in the Python sense, but that it evaluates a subset of
expressions that can be safely parsed.

>> 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.

ChrisA