Skip to content

threading.RLock must not support *args, **kwargs arguments #102029

Description

@sobolevn

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

See:

  1. def __init__(self):
  2. 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

Activity

added
type-bugAn unexpected behavior, bug, or error
stdlibStandard Library Python modules in the Lib/ directory
3.12only security fixes
on Feb 18, 2023
self-assigned this
on Feb 18, 2023

sobolevn commented on Feb 18, 2023

@sobolevn
MemberAuthor

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 commented on Feb 19, 2023

@sobolevn
MemberAuthor
added a commit that references this issue on Feb 20, 2023

gpshead commented on May 31, 2023

@gpshead
Member

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.

added
3.13only security fixes
and removed
3.12only security fixes
on Jun 1, 2023
added a commit that references this issue on Aug 17, 2023

hugovk commented on Nov 10, 2023

@hugovk
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

3.13only security fixesextension-modulesC modules in the Modules dirstdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions