gh-129724: Intern string constants in the compiler, not per code object - #159193

Compiling the same source could give code objects whose constants are shared differently, depending on which strings happened to be interned in the process. marshal then writes different bytes, so .pyc files were not reproducible (gh-129724).

Example

Two functions use an equal set constant. The compiler makes it one frozenset object, unless a string in it is already interned when the code objects are created:

1. fresh interpreter                        len(marshal.dumps(code))=398  f and g share one frozenset: True
2. same again                               len(marshal.dumps(code))=398  f and g share one frozenset: True
3. while another code object using the
   same strings is alive                    len(marshal.dumps(code))=408  f and g share one frozenset: False
4. after that code object is freed          len(marshal.dumps(code))=398  f and g share one frozenset: True

With this PR all four are 398 bytes with one shared frozenset. The same happened to the __qualname__ constant of a class body: compiling class A: class B: pass twice while the first result is alive gives different bytes on main.

Cause and fix

The compiler merges equal constants of a module through its constant cache. Interning then ran later, once per code object, in intern_constants(). A frozenset cannot be modified, so when one of its strings had to be replaced by an already interned string, that code object got a private copy.

flowchart TB
  subgraph before["main"]
    direction TB
    m1["compiler constant cache<br>one frozenset F for f and g"] --> m2["code object f<br>intern_constants()"]
    m1 --> m3["code object g<br>intern_constants()"]
    m2 -- "a string of F is<br>already interned" --> m4["F' = copy of F<br>with the interned string"]
    m3 -- "same" --> m5["F'' = another copy"]
    m4 --> m6["f and g no longer share:<br>marshal writes the set twice"]
    m5 --> m6
  end
  subgraph after["this PR"]
    direction TB
    n1["compiler constant cache<br>one frozenset F for f and g"] --> n2["intern_final_constants()<br>when f is assembled"]
    n2 -- "a string of F is<br>already interned" --> n3["F' built once and<br>stored in the cache entry of F"]
    n3 --> n4["g is assembled:<br>the cache gives F'"]
    n4 --> n5["f and g share F'<br>whatever was interned before"]
    n5 --> n6["intern_constants() in<br>the code object: nothing<br>left to replace"]
  end

• intern_final_constants() runs in optimize_and_assemble_code_unit(), after the optimizer and before the code object is created, on the constants the unit really ends up with. Strings that never reach a code object are not interned.
• Tuples are updated in place. A frozenset or slice is rebuilt at most once, and the result is stored in its constant cache entry so later code units get the same object.
• The qualified name of a class is interned by the compiler only where it would not be interned as a constant anyway.
• intern_constants() in Objects/codeobject.c is not changed; its should_intern_string() is renamed _PyCode_ShouldInternString() and exported so the compiler uses the same rule.

Behaviour changes

• Which strings get interned does not change, with one exception: identifier-like strings inside slice constants are now interned on the default build too, as they already were for every other kind of constant.
• Compared with main in a fresh process, 13 of 2078 stdlib files compile to different (smaller) bytes: constants that main always copied are now shared.
• compile() is about 0.5% slower on the default build (release, not PGO), which is inside the run-to-run noise.

Tests

TestConstantsIdentity in test_compile compiles a table of cases in child processes prepared in different ways (strings pre-interned, used as names, used as constants, the same source already compiled) and compares both the identity graph of the constants and the marshal output with a fresh process. It also covers tuples of names that are the same object as an equal constant (co_names of methods using a mangled name, keyword names, from lists, __static_attributes__), so that a change which re-creates those tuples per code object fails the test (the current version of draft #122180 does this).

With the marshal PR gh-159192 fixing the other half of gh-129724

Compiling each stdlib file under 14 different process conditions (file order, threads, pre-interned strings, earlier imports, hash seeds, keeping code objects alive) and comparing with one file per process:

The matrix was only run with all of these applied together. The three other fixes do not affect code compiled from source strings, which is all this matrix compiles.

drafted using Claude, reviewed & iterated upon by me.

(combined with the marshal fix, this will close the title issue)