`threading.RLock` must not support `*args, **kwargs` arguments

[sobolevn]

Right now we have an interesting problem: _CRLock supports *args, **kwargs in __new__, while _PYRLock does not.

See:

1. cpython/Lib/threading.py

   Line 133 in 128379b

   def __init__(self):

2. cpython/Modules/_threadmodule.c

   Line 506 in 128379b

   rlock_new(PyTypeObject *type, PyObject *args, PyObject *kwds)

   (they are unused)

I am leaving aside the problem that _PYRLock is not ever used (unless imported directly) for now.

Right now our docs does not say what the signature should be.
Some facts:

1. CPython's code never use RLock with arguments (and never say it has arguments)
2. typeshed (a source of truth for all typecheckers and several IDEs never had a single issue about missing *args, **kwargs in their RLock's stub: https://github.com/python/typeshed/blob/0bb7d621d39d38bee7ce32e1ee920bd5bc4f9503/stdlib/threading.pyi#L113-L119
3. We don't have any docs about RLock's signature

So, I think we can:

1. Document that RLock has () signature
2. Remove *args, **kwargs from C impl
3. Document this in "What's new"

Does it sound like a plan? If yes, I would like to do the honours :)

Linked PRs

• gh-102029: Deprecate passing arguments to _PyRLock in threading #102071

[sobolevn]

Or even it migth be a good time to also deprecate _PyRLock completely?

See #57906
This was discussed even 11 years ago. Maybe the time has come? :)

[sobolevn]

CC @njsmith @pitrou

[gpshead]

History:

Python up through 2.7 and 3.1 threading.RLock supported an undocumented verbose argument. https://github.com/python/cpython/blob/v2.7.18/Lib/threading.py#L132

It was still explicitly allowed but pulled out from the args in 3.2 even though it was not passed on to the new _CRLock.

There is a very tiny amount of code out there that still blindly passes a value for this (now no-op) argument. The fix to such code is trivial: remove the no-op argument.

[hugovk]

Anything more to do here, or can we close this issue?