gh-132578: Rename the threading.Thread._handle field
#132696
Conversation
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.
|
I'm on the fence about backporting this to 3.13. It has the potential to break code that's started relying on How common is the breakage? How much does this block from upgrading to 3.13? |
|
3.13.3 is out already, it sounds unlikely that some library wanting to support 3.13 is still blocked by this bug (the workaround is near trivial). So my vote is against backporting. |
It's hard to say. A quick GitHub search doesn't have too many results, so I suspect it's not that widespread. |
|
Thanks @mpage for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13. |
…H-132696) 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>
|
GH-132789 is a backport of this pull request to the 3.13 branch. |
Commit 0e9c364 introduced the
_handlefield on instances ofthreading.Thread. Unfortunately it's fairly common for subclasses ofthreading.Threadto define a_handle()method, which is shadowed by the new field.Search results on GitHub suggests that the new name is unlikely to collide with existing code (results for the old name).
Name mangling is a bit of an awkward fit here because subclasses of
threading.Threadneed access to the handle.