Introduction of Thread._handle: _thread._ThreadHandle in Python3.13 has broken an unknown number of packages

Bug report

Bug description:

To open with- Python is great, probably the language I have written the most code in; super excited for the progressing into no-GIL, at my day job we've built a massive Python system and we're hopeful that no-GIL (at least for parts of it) will help with a bunch of perf issues that we're presently either enduring or have built complexity to work around.

Onto the issue; in the code of a number now-broken (since Python 3.13) packages (if you Google around for TypeError: '_thread._ThreadHandle' object is not callable you'll get a feel for it), we'll likely see something roughly like this (I believe this is a bit of a common pattern):

class SomeThread(threading.Thread):
    def __init__(self):
        threading.Thread.__init__(self)
        self.stopped = threading.Event()    

    def _handle(self):
        some_logic_here()

    def run(self):
        while not self.stopped.is_set():
            self._handle()

However, since Python 3.13, attempts to use this pattern result in failures like like this:

Traceback (most recent call last):
  File "/Users/edwardbeech/.venv/ims-mono-py3.13/lib/python3.13/site-packages/ims_utils/utils/thread_utils.py", line 208, in _do_tasks_and_return_duration
    self.tasks()
    ~~~~~~~~~~^^
  File "/Users/edwardbeech/Projects/FTP/ims-mono/wireless-manager-back-end/other/tcp/tcp_socket.py", line 111, in tasks
    self._handle()
    ~~~~~~~~~~~~^^
TypeError: '_thread._ThreadHandle' object is not callable

I believe this is because of the introduction of this code in threading.py; truncated excerpt:

class Thread:
    ....
    def __init__(self, group=None, target=None, name=None,
        ...
        self._handle = _ThreadHandle()

Now, for sure- arguably this pattern is problematic in general because threading.Thread has a bunch of sunder-private properties that this pattern risks clobbering and probably the right thing to do is to use threading.Thread.__init__(target=your_run_func)- but if we consider Hyrum's Law (relevant xkcd) we could re-frame this such that prior to Python 3.13, everyone's usage of threading.Thread was in-keeping with the "interface" (if you can call it that) supported by threading.Thread (despite the dubious and accidental "swiss cheese symbiosis" of property naming) and from Python 3.13 onwards, we've broken that interface for people.

I don't know enough about internal Python development to know if there's a strategy with these sorts of things e.g. perhaps we're happy to break userspace and folks must simply revise their libraries (and if so, then that's fine, I'm happy with that answer).

If there is no such strategy though and we're more focused on interoperation across versions, I think an easy fix here would be to just change to be a dunder property instead of a sunder property and call it a day- I would probably warn against changing all the other existing sunder properties to dunder properties though because again, who knows who is relying on them in some odd way as an interface lol.

Here's some Docker-based testing I was doing; probably not really needed to paint the picture:

docker run --rm -it --entrypoint python3 python:3.12 -c 'from threading import Thread; t = Thread(); print(repr(t._handle)) if hasattr(t, "_handle") else print("property does not exist")'
property does not exist

docker run --rm -it --entrypoint python3 python:3.13 -c 'from threading import Thread; t = Thread(); print(repr(t._handle)) if hasattr(t, "_handle") else print("property does not exist")'
<_thread._ThreadHandle object: ident=0>

docker run --rm -it --entrypoint python3 python:3.14.0a7 -c 'from threading import Thread; t = Thread(); print(repr(t._handle)) if hasattr(t, "_handle") else print("property does not exist")'
<_thread._ThreadHandle object: ident=0>

CPython versions tested on:

3.13

Operating systems tested on:

macOS

Linked PRs

• gh-132696
• gh-132789
• gh-150322

Beginne mit Lib/threading.py bei der zitierten Zuweisung in Thread.init und reproduziere das Verhalten mit den Docker-Befehlen für Python 3.12, 3.13 und 3.14. Prüfe die verknüpften PRs und die Diskussion; als abgeschlossen gilt die Arbeit erst, wenn eine vereinbarte Kompatibilitätslösung für Subklassen vorliegt, die _handle definieren, und das Verhalten über die betroffenen Versionen hinweg validiert wurde.