So to clarify, the risk here is that the default build will leak a bunch of names if code is created dynamically (by using exec or whatever), each time using a different name, then freed?

How significant is the scaling improvement on the free-threading build?

Honestly, I'm not too worried since we already intern names and constants and stuff.

Do you have any numbers on how many extra strings this will intern?

How significant is the scaling improvement on the free-threading build?

It's critical for some common patterns, although it's not the only critical bottleneck (there are other remaining bottlenecks too).

For example:

def run_in_parallel():
    def foo():
        pass
    return foo

If run_in_parallel() is run from multiple threads concurrently, then the construction of different foo functions would be a bottleneck due to the functions taking their names from the code object. (The names are refcounted).

Do you have any numbers on how many extra strings this will intern?

Running test_threading (chosen arbitrarily) I see the number of interned unicode strings change:

before this PR: 19419
after this PR: 19721

(in the default build, as reported by sys.getunicodeinternedsize())

Running test_threading (chosen arbitrarily) I see the number of interned unicode strings change:

before this PR: 19419 after this PR: 19721

(in the default build, as reported by sys.getunicodeinternedsize())

The increase from 19419 to 19721 doesn't seem so bad, but it depends on the baseline.
As an extreme example, if 19418 of those are interned by python -c "pass" then it is an increase from 1 to 300 which is bad.

Can you get numbers for something like the mypy benchmark or a similar "realistic" program?

./python -m mypy --config-file Lib/test/libregrtest/mypy.ini
before: 25643
after: 25789

And ./python -c "pass"
before: 3926
after: 4070

I'm going to go ahead and merge this as the increase seems small, especially for larger programs.