[3.13] gh-132578: Rename the threading.Thread._handle field (GH-132696)#132789
[3.13] gh-132578: Rename the threading.Thread._handle field (GH-132696)#132789miss-islington wants to merge 1 commit into
threading.Thread._handle field (GH-132696)#132789Conversation
…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>
|
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. |
|
Disregard the approve, pressed the button in the wrong PR |
|
This PR is stale because it has been open for 30 days with no activity. |
Commit
0e9c364fintroduced the_handlefield on instances ofthreading.Thread. Unfortunately it's fairly common for subclassesof
threading.Threadto define a_handle()method, which is shadowedby the new field.
(cherry picked from commit 3cfab44)
Co-authored-by: mpage mpage@meta.com