On 2017-02-27, Chris Angelico <ros...@gmail.com> wrote:
> On Tue, Feb 28, 2017 at 3:17 AM, Jon Ribbens <jon+use...@unequivocal.eu>
> wrote:
>> On 2017-02-27, Chris Angelico <ros...@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.
>> 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).
> 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?
>> 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.
>> (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 )
>
> Technically they're called "set display", too. Does it count as a
> literal if and only if all members are literals?
That seems to be the unavoidable consequence of the definition, yes.
> 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!
> 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.
> 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.
--
https://mail.python.org/mailman/listinfo/python-list
