Re-raising the bug reported by Kevin Shweh:
thread: https://bugs.python.org/issue14385
message: https://bugs.python.org/msg337245

Here is a copy for easier reference:

The patch for this issue changed LOAD_GLOBAL to use PyObject_GetItem when globals() is a dict subclass, but LOAD_NAME, STORE_GLOBAL, and DELETE_GLOBAL weren't changed. (LOAD_NAME uses PyObject_GetItem for builtins now, but not for globals.)

This means that global lookup doesn't respect overridden __getitem__ inside a class statement (unless you explicitly declare the name global with a global statement, in which case LOAD_GLOBAL gets used instead of LOAD_NAME).

I don't have a strong opinion on whether STORE_GLOBAL or DELETE_GLOBAL should respect overridden __setitem__ or __delitem__, but the inconsistency between LOAD_GLOBAL and LOAD_NAME seems like a bug that should be fixed.

For reference, in the following code, the first 3 exec calls successfully print 5, and the last exec call fails, due to the LOAD_GLOBAL/LOAD_NAME inconsistency:

class Foo(dict):
    def __getitem__(self, index):
        return 5 if index == 'y' else super().__getitem__(index)
 
exec('print(y)', Foo())
exec('global y; print(y)', Foo())
exec('''
class UsesLOAD_NAME:
    global y
    print(y)''', Foo())
exec('''
class UsesLOAD_NAME:
    print(y)''', Foo())


I encountered the same issue when trying to create a way to "instantiate" modules with some globals replaced by user-defined values to make a dependency-injection system. I therefore want to lookup some names in a separate dict rather than getting the value normally bound in that module (typically by an import statement).

Is this issue duplicate of https://bugs.python.org/issue32615 and https://bugs.python.org/issue1402289 ?

Looks like it is, for some reason I did not find these previous issues when looking for existing ones.

Both preceding issues were closed as rejected.

If you want to change that decision, I suggest posting on python-ideas list explaining why you disagree and get support for a change now.

I ended up with a slightly different API that allows me to preemptively set some global names before the code runs in the module, so my use case sort of vanished. I don't think there is a real need of beating the dead horse here.

My only suggestion on the topic is that since the feature is not documented and is not really usable anyway, we might as well remove the slow path in LOAD_GLOBAL (unless there is a use case for having LOAD_GLOBAL and not LOAD_NAME I'm missing)