[3.13] gh-132578: Rename the threading.Thread._handle field (GH-132696)

[miss-islington]

Commit 0e9c364f introduced the _handle field on instances of
threading.Thread. Unfortunately it's fairly common for subclasses
of threading.Thread to define a _handle() method, which is shadowed
by the new field.
(cherry picked from commit 3cfab44)

Co-authored-by: mpage mpage@meta.com

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

[Yhg1s]

Let's hold off on merging this until we've got a clearer picture of the extent of the breakage and the risk of this change. (See #132696 (comment))

[hellypi]

Let's hold off on merging this until we've got a clearer picture of the extent of the breakage and the risk of this change. (See #132696 (comment))

You broke every package that was relying on _handle not being a shadowing, so we are past the stage of worrying about breaking previously unbroken libraries. There currently is a way smaller amount of packages that rely on _handle. I would argue for renaming as soon as possible, since newly created packages are more likely to still be maintained compared to older packages.

[pablogsal]

Disregard the approve, pressed the button in the wrong PR

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[vstinner]

This backport PR is open for 1 year. IMO it's not too late to merge it. Developers had enough time to update their code to manage the _handle name conflict.

[kumaraditya303]

Agreed, closing it.