There's something I don't quite feel is right in the current doc about exec with both globals and locals arguments supplied:

If exec gets two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition.

This is unclear, because elsewhere (in Language Reference > Data Model, it says that the two are only "approximately" analogous:

The key difference from a normal call to exec() is that lexical scoping allows the class body (including any methods) to reference names from the current and outer scopes when the class definition occurs inside a function.

Indeed this is a "key difference": a class block inside a def block can "dereference" a cell variable bound in the enclosing def block. I think the bytecode emitted is called LOAD_CLASSDEREF. This is not available to exec() because the information about which variable is a cell variable has been fixed before the dynamic exec().

This works:

>>> def f():
...     fcvar = 0
...     def g():
...         class C:
...             a = fcvar
...     g()
>>> f()

This doesn't:

>>> def h():
...     hcvar = 0
...     def henc():
...         exec("a = hcvar", globals(), locals())
...     henc()
>>> h()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in h
  File "<stdin>", line 4, in henc
  File "<string>", line 1, in <module>
NameError: name 'hcvar' is not defined

The exec() call in function henc cannot just "magically" access hcvar as if the statement in the string were compiled with the rest of the program. The compiler doesn't know what the characters "hcvar" mean in the string literal passed to exec(). Unless, of course, if we accommodate rest of the program to it:

...     def henc():
...         hcvar
...         exec("a = hcvar", globals(), locals())

But this works for a totally different reason -- we've already dereferenced the cell variable in the henc block. There are still further differences, such as not being able to say nonlocal hcvar in the string as if the statement were embedded in the program.

So, what if we just... remove that sentence?

If exec gets two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition.

Also, the footnote on exec() expecting LF newline only.

Note that the parser only accepts the Unix-style end of line convention. If you are reading the code from a file, make sure to use newline conversion mode to convert Windows or Mac-style newlines.

Is this still true? (Edit: the footnote was introduced in 2009. It's no longer the same parser anymore...)

>>> exec("print('foo')\r\nprint('bar')\r\n")
foo
bar

Also I'd like to be more affirmative in the Note box on "modifying the default local namespace returned by locals()", but it seems so far the live modification of the default local namespace is indeed not a well-defined thing. (I wouldn't use the phrase "undefined behaviour", but my understanding is that it involves too much implementation detail). If PEP 558 becomes standard, perhaps we can say something more definitive about modifying the locals.

I've updated the PR with a new commit, in the hope that clarity/accuracy is further improved.

If the review is in favour of the proposed revision, I'll add a NEWS entry.

This PR is stale because it has been open for 30 days with no activity.

This unfortunately has a couple of merge conflicts now. Would you mind fixing those?

@congma Would you still be interested in fixing the merge conflicts? I can open a separate one to get the conflicts resolved if not.

See #100003 for conflict resolution of the eval section

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be put in the comfy chair!

This has merge conflicts now.

This does have merge conflicts, so a new PR (#100003) was opened to resolve part of the conflict. I'll open another PR on exec once eval's good to go since there's some duplication in there.

The following commit authors need to sign the Contributor License Agreement:

• cong.ma@uct.ac.za