`FrameLocalsProxy` is stricter than `dict` about what constitutes a match

[da-woods]

Bug report

Bug description:

import inspect

class MyString(str):
    pass

def f():
    a = 1
    locals = inspect.currentframe().f_locals
    print(MyString("a") in locals)

f()

In Python 3.12 and below this prints True. In Python 3.13 this print False. I think it comes down to the check for exact unicode:

cpython/Objects/frameobject.c

Line 112 in f4ddaa3

if (PyUnicode_CheckExact(key)) {

The change in behaviour isn't a huge problem so if it's intended then I won't spend waste any time complaining about it, but I do think it's worth confirming that it is intended/desired.

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Linked PRs

• gh-120906: Support arbitrary hashable keys in FrameLocalsProxy  #122309
• [3.13] gh-120906: Support arbitrary hashable keys in FrameLocalsProxy (GH-122309) #122488

[gaogaotiantian]

Interesting issue. I don't have a definitive answer here but this is something we need to deal with, because we are getting some weird issues here:

import sys
class MyString(str):
    pass

def f():
    x = 1
    local = sys._getframe().f_locals
    local[MyString('x')] = 2
    print(local.keys())
    # ['x', 'local', 'x']
    print(local)
    # {'x': 2, 'local': {...}}

f()

Internally we check if the input key is an exact unicode, but we do utilize dict for certain features (repr for example). This causes an inconsistent behavior.

My preferred solution is to enforce any key to be an exact unicode string. The reason for that is, unlike a generic dict, FrameLocalsProxy should be a direct proxy for local variables and keys other than unicode string does not quite make sense. However, I know I'm the more aggressive type when it comes to changes so I'll list some concerns as well.

frame.f_locals for an unoptimized frame (module/class) is a real dict and can take any type of keys. There might also be a usage to use a subclass as keys? If the original usage is shown to be helpful, that might tip the scale for me.

I'm a bit worried about the can of worms when we allow subclasses of unicode strings - what if it overwrite the __hash__ and __eq__ methods? Will it cause more troubles than the benefits?

[da-woods]

Just to explain the context I ran into it in:

The Cython compiler wraps most of it's strings into an EncodedString class (for reasons that are possibly historic and which I don't quite understand). To clarify - that's a class used internally by the compiler, rather than a class used in Cython extension modules.

We have an inline method of compilation, and here missing variables are taken from the surrounding frame. The frame comes from Python so the variable names are just a normal str. However the names we're using to look them up are our EncodedString class. These used to work fine when used to look up keys (since they just matched the equivalent str) but now don't.

It's easy enough to work around so I'm relaxed about the solution whatever you decide to do. I think what we were doing was mostly accidental and there wasn't a hidden special use-case behind it.

But for this use-case I'm just reading existing values from the FrameLocalsProxy and not worried about storing subclassed strings. Obviously you need to consider both sides of it though.

[gaogaotiantian]

We need to discuss this further with @markshannon, but I think the desired behavior would be either

• Report an error when the key is not an exact unicode string
• or allow all string-like (subclasses of unicode) keys and access the actual fast locals even with those strings.

[gaogaotiantian]

I just remembered that we already had that discussion when I was implementing PEP 667. The PEP suggests that we should allow arbitrary types.

Then the question would be what if the user gives a unicode-like key, do we try to access the fast variables with that key?

[ncoghlan]

To avoid breaking mapping invariants, if a given key compares equal to the name of a local variable, it needs to be handled as a lookup of that variable name. Having a PyUnicode_CheckExact guard on a string comparison fast path still makes sense, but the fallback needs to be a linear search using the abstract object comparison API rather than assuming the key is absent.