builtins.globals() fails to update after a comprehension with colliding variable in Python 3.12

[kycutler]

Environment data

• debugpy version: 1.8.12
• OS and version: Windows 11
• Python version (& distribution if applicable, e.g. Anaconda): 3.12.8
• Using VS Code or Visual Studio: VS Code

Actual behavior

Run and debug the following, with a breakpoint on the last line:

# Global variable
foo = None

# Comprehension with colliding local variable
[foo for foo in [0]]

# Breakpoint here
debugger()

While paused, evaluate the following in debug console:

import builtins

builtins.globals()["abc"] = 123

builtins.globals()["abc"]

Notice the last evaluation fails with a KeyError, even though it should have been set.

This issue only reproduces under the following circumstances:

• Python 3.12 (any patch version -- but 3.11 and 3.13 both work)
• The code is in global scope
• The iteration variable in the comprehension collides with the global variable

Expected behavior

The assignment to builtins.globals() should persist between evaluations

[rchiodo]

Python 3.12 (any patch version -- but 3.11 and 3.13 both work)

If that's the case, it's likely this was a bug in the CPython runtime.

[kycutler]

@rchiodo I'm sure it's related to the Python 3.12 implementation, but it may not be a bug there either -- rather I suspect it's specific to the way debugpy handles globals during evaluation, e.g. here. I'm wondering if it might be more appropriate for debugpy to work around the difference.

Also, it appears to be more general than just the case with builtins above -- the issue also appears when just evaluating:

x = 1 # OK

y = 1 # OK

y     # NameError: name 'y' is not defined

[rchiodo]

I can't seem to reproduce it myself.

That was with 3.12.

There was something similar a while back though.
#1636

Are you sure you're using 1.8.12 for debugpy?

[kycutler]

Strange -- did you use the script above, with breakpoint at the end? It repros consistently for me across multiple machines / environment types (venv, conda) under those conditions.

It seems likely that #1636 is the same issue. We originally encountered this in a larger script (with lots of variables / chances for collision) and gradually boiled it down to the above.

Here's the full screenshot of my repro / versions:

[rchiodo]

No, I didn't use your original script. I can now reproduce your issue with 3.12, but not 3.13. I wonder what in that script is breaking things.

I don't think it would be worth investigating though if the workaround is update to 3.13. This code has been around for many years (only change recently was to change single quotes to double quotes)