Weird `int.__str__` behaviour inside sub-interpreters

Bug report

Bug description:

Hi Python maintainers!

I noticed something weird when using subinterpreters, while converting an Enum to string I get an unexpected result. This occurs in Python 3.12 and 3.13.

Here's an script to reproduce it:

import _xxsubinterpreters as interpreters


script = """from enum import _simple_enum, IntEnum

@_simple_enum(IntEnum)
class MyEnum:
    DATA = 1
    
print(str(MyEnum.DATA))
"""

exec(script)
# Output: 1

interp_id = interpreters.create(isolated=False)
interpreters.run_string(interp_id, script)
# Output: <MyEnum.DATA: 1>, Expected: 1

In all python versions previous to 3.12 this prints "1" two times, on newer versions I get <MyEnum.DATA: 1> when running inside a subinterpreter. For some reason, the __str__ function being used is different on new Python versions.

I also noticed that the function pointed by __str__ is different inside and outside the subinterpreter.

Outside:

...
print(MyEnum.DATA.__str__)
# Output: <method-wrapper '__repr__' of MyEnum object at 0x7f9a09a2e910>

Inside:

...
print(MyEnum.DATA.__str__)
# Output: <method-wrapper '__str__' of MyEnum object at 0x7f9a099a5e90>

NOTE: I'm creating subinterpreters passing the isolated=False flag, which uses the Legacy init config.
I first noticed the error on MacOS, then reproduced using Docker with various Python versions.

I hope this is enough to get to the source of the issue.

Appreciate all your work and effort on building Python, thank you!

CPython versions tested on:

3.8, 3.9, 3.10, 3.11, 3.12, 3.13

Operating systems tested on:

Linux, macOS

Linked PRs

• gh-117660
• gh-121602
• gh-121630
• gh-121632
• gh-121636
• gh-121862
• gh-121882
• gh-121932
• gh-122192
• gh-122195
• gh-122197
• gh-122241
• gh-122248
• gh-122249
• gh-122250
• gh-122865
• gh-122866
• gh-122867

Beginne damit, den bereitgestellten _xxsubinterpreters-Reproducer mit enum._simple_enum auszuführen und MyEnum.DATA.str innerhalb und außerhalb des Subinterpreters zu vergleichen. Verfolge die relevanten CPython-Laufzeit- und enum-Einstiegspunkte und überprüfe anschließend, dass das Verhalten der erwarteten String-Konvertierung über die betroffenen Python-Versionen hinweg entspricht; im Issue sind viele verknüpfte PRs aufgeführt, die zuerst geprüft werden sollten.