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 forTypeError: '_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):

classSomeThread(threading.Thread):def__init__(self):threading.Thread.__init__(self)self.stopped=threading.Event()def_handle(self):some_logic_here()defrun(self):whilenotself.stopped.is_set():self._handle()

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

Traceback (mostrecentcalllast):File"/Users/edwardbeech/.venv/ims-mono-py3.13/lib/python3.13/site-packages/ims_utils/utils/thread_utils.py",line208,in_do_tasks_and_return_durationself.tasks()~~~~~~~~~~^^File"/Users/edwardbeech/Projects/FTP/ims-mono/wireless-manager-back-end/other/tcp/tcp_socket.py",line111,intasksself._handle()~~~~~~~~~~~~^^TypeError:'_thread._ThreadHandle'objectisnotcallable

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

classThread:    ....def__init__(self,group=None,target=None,name=None,        ...self._handle=_ThreadHandle()

Now, for sure- arguably this pattern is problematic in general becausethreading.Thread has a bunch of sunder-private properties that this pattern risks clobbering and probably the right thing to do is to usethreading.Thread.__init__(target=your_run_func)- but if we considerHyrum's Law (relevant xkcd) we could re-frame this such that prior to Python 3.13, everyone's usage ofthreading.Thread was in-keeping with the "interface" (if you can call it that) supported bythreading.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 existdocker 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-132578: Rename thethreading.Thread._handle field #132696
• [3.13] gh-132578: Rename thethreading.Thread._handle field (GH-132696) #132789