This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author bruno.loff
Recipients bruno.loff, congma, docs@python, terry.reedy
Date 2021-03-26.20:49:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1616791749.9.0.407871204451.issue43605@roundup.psfhosted.org>
In-reply-to
Content
Hmm... OK, if I understand correctly, the evaluation procedure for a (e.g.) list comprehension, as described in the documentation you linked in, is as follows:

* The generator in the leftmost for expression is evaluated in the current local scope. (doc: "The iterable expression in the leftmost for clause is evaluated directly in the enclosing scope and then passed as an argument to the implicitly nested scope.")
* A new nested scope is created, and the iterator object is passed to that new scope as an argument.
* The other for and if clauses are evaluated in the new scope.

As you mention, the documentation does not properly describe in which scope is evaluated the leftmost expression that generates each object (to be placed in the list).

You say that the leftmost expression is also not evaluated in the enclosing scope (which I take means that it is being evaluated in the new nested scope). But notice that sometimes it *seems to be*.

There are two inconsistent behaviors:

1) If evaluated outside of an eval, using local objects works just fine. It is then reasonable to assume that the leftmost expression has access to the locals() of the function it is in. (see the line with the comment `# works as expected` in the first post I made).

2) If evaluated inside an eval the leftmost expression cannot access the locals (see the example I gave). This happens even when locals() is passed to the __locals argument of the call to `eval`.

It seems reasonable that behavior (1) should happen in both cases. In fact, I think it is *very* reasonable to expect that calling eval() on a string should have the exact same effect as if the code that is inside the eval had been written as part of the source code. Don't you think? I believe that this is exactly what happens, e.g., in Lisp.

I would guess this is just a bug, but maybe there is some technical reason why this is not possible. If that is (sadly) the case, this should be explained in the documentation.

Currently I don't really have a mental model for what happens when I call `eval`.
History
Date User Action Args
2021-03-26 20:49:09bruno.loffsetrecipients: + bruno.loff, terry.reedy, docs@python, congma
2021-03-26 20:49:09bruno.loffsetmessageid: <1616791749.9.0.407871204451.issue43605@roundup.psfhosted.org>
2021-03-26 20:49:09bruno.lofflinkissue43605 messages
2021-03-26 20:49:09bruno.loffcreate