gh-102029: Deprecate passing arguments to _PyRLock in threading
#102071
Conversation
sobolevn
changed the title
__new__ sigs of _CRLock and _PyRLock in threading__new__ sigs of _CRLock and _PyRLock in threading
sobolevn
force-pushed
the
issue-102029
branch
from
d634476 to
4529493
Compare
|
@pablogsal friendly ping :) |
|
Thank you! In the meantime, I will change the |
|
note to self: I included this PR in an internal test run today, I'll have results by tonight/tomorrow. |
|
hypothesis failures are not related. |
|
I found only a single instance of a parameter being passed to RLock via testing this change in our huge codebase at work:
That code was originally written for Python 2.7 which did support an undocumented Easy to fix. But it does suggest that we should just do this API change via our usual DeprecationWarning cycle rather than just assuming we can make it without notice. |
Doc/whatsnew/3.13.rst
Outdated
|
|
||
| * Passing any arguments to :func:`threading.RLock` is now restricted. | ||
| Previously C version allowed any numbers of args and kwargs, | ||
| but they were just ignored. Python version never allowed any arguments. |
There was a problem hiding this comment.
This statement isn't accurate; Python <= 2.7 and 3.1 accepted a single undocumented verbose argument.
Lib/threading.py
Outdated
| @@ -107,7 +107,7 @@ def gettrace(): | |||
|
|
|||
| Lock = _allocate_lock | |||
|
|
|||
| def RLock(*args, **kwargs): | |||
| def RLock(): | |||
There was a problem hiding this comment.
Lets do a regular DeprecationWarning API change cycle on this.
if args or kwargs:
warnings.warn(DeprecationWarning, ...)
we can put that in 3.12 remove the ignored args/kwargs in 3.14.
There was a problem hiding this comment.
I thought that 3.12 is now only accepting bugfixes, isn't it? I would prefer to have this change as safe as possible and to put it in 3.13+. Unless you insist :)
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase And if you don't make the requested changes, you will be poked with soft cushions! |
|
I have made the requested changes; please review again |
|
Thanks for making the requested changes! @gpshead: please review the changes made to this pull request. |
sobolevn
changed the title
__new__ sigs of _CRLock and _PyRLock in threading_PyRLock in threading
|
@gpshead now this is deprecated in 3.13 and stated to be changed in 3.15 :) |
|
Closing and re-opening to retrigger CLA checks. Sorry for the noise. |
|
Thanks everyone! CI is now green :) |
|
Can someone please click "merge"? :) |
I hope that this is not really a breaking change. Here's my reasoning:
_PyRLockwas the first one (since python2). People are familiar with it: and its signature was always correctRLockis exposed as a function)typeshedalways hadRLockdefined as() -> RLockwith no complains: https://github.com/python/typeshed/blob/40d853cbe239bcf1479e25c2c59615158b672610/stdlib/threading.pyi#L115-L122RLockwith argumentsAs the next step, I will propose to deprecate the Python version.
threading.RLockmust not support*args, **kwargsarguments #102029