Eryk Sun added the comment:
> You seem to be arguing that a description in the docs is "misleading",
> not because it misleads, but because it don't describe a situation
> which has nothing to do with the situation that the docs are describing.
To me it's misleading to say "the code will be
Quentin Peter added the comment:
Maybe a note could be added to
https://docs.python.org/3/library/functions.html#exec
Something along the lines of:
Note: If exec gets two separate objects as `globals` and `locals`, the code
will not be executed as if it were embedded in a function
Steven D'Aprano added the comment:
On Thu, Dec 23, 2021 at 05:47:33AM +, Eryk Sun wrote:
>
> Eryk Sun added the comment:
>
> > That's taken straight out of the documentation.
>
> Yes, but it's still a misleading comparison.
I asked how you would re-word the docs, but you haven't
Eryk Sun added the comment:
> That's taken straight out of the documentation.
Yes, but it's still a misleading comparison.
> Until I understood that exec with two different mapping objects as
> globals and locals behaves as if the code where embedded inside a
> class, I found the reported
Steven D'Aprano added the comment:
On Thu, Dec 23, 2021 at 12:15:29AM +, Eryk Sun wrote:
>
> Eryk Sun added the comment:
>
> > If exec gets two separate objects as globals and locals,
> > the code will be executed as if it were embedded in a
> > class definition.
>
> That's a
Eryk Sun added the comment:
> If exec gets two separate objects as globals and locals,
> the code will be executed as if it were embedded in a
> class definition.
That's a misleading comparison because a class definition intentionally
supports nonlocal closures, which exec() doesn't
Steven D'Aprano added the comment:
"Expected" is a strong word. It took me a lot of careful reading of the
documentation and experimentation to decide that, yes, I expect the
second case to fail when the first case succeeds.
Which reminds me of a common anecdote from mathematics:
Quentin Peter added the comment:
Thank you for your explaination. Just to be sure, it is expected that:
exec("a = 1\ndef f(): return a\nprint(f())", {})
Runs successfully but
exec("a = 1\ndef f(): return a\nprint(f())", {}, {})
Doesn't?
--
___
Steven D'Aprano added the comment:
> I now want to define a closure with exec. I might want to do something like:
> exec("def f(): return a", globals(), locals())
That doesn't create a closure.
> I would expect f() to look for a in the locals().
I'm sorry, but your expectation that f()
Steven D'Aprano added the comment:
Here is the key phrase in the docs:
"If exec gets two separate objects as globals and locals, the code will be
executed as if it were embedded in a class definition."
https://docs.python.org/3/library/functions.html#exec
And sure enough:
>>> class C:
...
Quentin Peter added the comment:
The reason I am asking is that I am working on a debugger. The debugger stops
on a frame which is inside a function. Let's say the locals is:
locals() == {"a": 1}
I now want to define a closure with exec. I might want to do something like:
exec("def f():
Steven D'Aprano added the comment:
The function you use in exec is not a closure. The function:
def f():
return a
does not capture the top-level variable "a", it does a normal name lookup for
a. You can check this yourself by looking at f.__closure__ which you will see
is None.
12 matches
Mail list logo
