Eval of code objects does not always fill passed locals dictionary

[lejar]

Bug report

Bug description:

When passing a code object to the eval (doc) builtin, I am observing that the locals dictionary is not always filled with the variables created inside of the code. For example:

import textwrap

def foo_func():
    a = 1
    b = 2

foo_str = compile(
    textwrap.dedent("""\
        a = 1
        b = 2
        """
    ),
    '<file>',
    'exec',
)


glb = globals()
loc = {}

eval(foo_func.__code__, glb, loc)
print('foo_func', loc)

eval(foo_str, glb, loc)
print('foo_str', loc)

produces the output:

foo_func {}
foo_str {'a': 1, 'b': 2}

I would expect the output to be the same for both calls.

CPython versions tested on:

3.13

Operating systems tested on:

Linux, macOS

[lejar]

I think what might be happening is that in Python/ceval.c:initialize_locals the locals dictionary is copied to _PyInterpreterFrame::localsplus. The function executes using localsplus and the contents of localsplus are never copied back to the locals dictionary.

[srinivasreddy]

Are you working on it ?

[lejar]

Kind of. I have something which seems to be working, but honestly I don't know what I'm doing and if there are any consequences down the road.

--- a/Python/ceval.c
+++ b/Python/ceval.c
@@ -1899,7 +1899,22 @@ _PyEval_Vector(PyThreadState *tstate, PyFunctionObject *func,
         return NULL;
     }
     EVAL_CALL_STAT_INC(EVAL_CALL_VECTOR);
-    return _PyEval_EvalFrame(tstate, frame, 0);
+    PyObject* result = _PyEval_EvalFrame(tstate, frame, 0);
+
+    if (locals && locals != Py_None)
+    {
+        for (int i = 0; i < ((PyCodeObject *)(func->func_code))->co_nlocalsplus; i++) {
+            if (PyStackRef_IsNull(frame->localsplus[i]))
+                continue;
+
+            PyObject *name = PyTuple_GET_ITEM(((PyCodeObject *)(func->func_code))->co_localsplusnames, i);
+            PyObject *value = PyStackRef_AsPyObjectBorrow(frame->localsplus[i]);
+
+            PyDict_SetItem(locals, name, value);
+        }
+    }
+
+    return result;
 }```

[gaogaotiantian]

I don't believe this is a bug. It's also not a regression as it has been like this for a while. The issue is, the two "executables" you passed in are not equivalent. The code object of a function accesses the "real" local variables, which are fast variables. So the local scope you sent did not do anything. As for the code string, it was compiled as being put in a class definition (which is documented), so the local scope actually does something. Two different code producing two different results is not a bug.

As for the documentation, there might be some space for improvement. I'm not the expert there. I don't really think the behavior contradicts the docs, but it's not super clear either.

[lejar]

Of course I would prefer if the behavior were the same for the two different code objects, but if it not seen as a bug then I agree that the documentation should be updated to represent this.

If I were to continue working on this and recover the values inside of the localsplus list, then would it have a chance of being accepted / incorperated?

[gaogaotiantian]

Like I said, the two code objects are not the same - making the behavior the same would be a bug.

Also, this is the direction we are trying to get away from. We don't want the implicit conversions between fast variables and a dict at random places - that's why we removed those utilities and implemented PEP 667.