Uh oh!
There was an error while loading. Please reload this page.
gh-89554: Document _thread.LockType as a class - #150684
Conversation
Documentation build overview
5 files changed · |
gaborbernat
commented
Jun 1, 2026
Backward-compatibility check. No independent references to |
| .. class:: LockType | ||
| This is the type of lock objects. | ||
There was a problem hiding this comment.
dir() lists the following methods: ['_at_fork_reinit', 'acquire', 'acquire_lock', 'locked', 'locked_lock', 'release', 'release_lock'].
acquire(), release() and locked can be documented. It means moving the existing documentation to here: https://docs.python.org/dev/library/_thread.html#thread.lock.acquire.
To reduce the diff, maybe move the LockType doc where acquire() is currently documented?
9c3fc41 to
d1af26eCompareUh oh!
There was an error while loading. Please reload this page.
d1af26e to
77c89a3Compare77c89a3 to
343add6Compare| c-api/import.html: c.PyImport_LazyImportsMode.PyImport_LAZY_NONE | ||
| # gh-89554: _thread lock methods are now documented under the LockType class | ||
| library/_thread.html: thread.lock.acquire |
There was a problem hiding this comment.
Can these not be avoided by creating labels at the relevant locations?
There was a problem hiding this comment.
Not in a way the check accepts, unfortunately. These anchors are object IDs emitted by the .. method:: directive, and they keep the dots (thread.lock.acquire). A reST label or target goes through docutils.nodes.make_id(), which collapses every run of non-alphanumeric characters to a single hyphen, so a label can only ever produce thread-lock-acquire — a different anchor. check-html-ids.py compares exact ID strings, so the dotted thread.lock.acquire would still register as removed.
Since the methods are intentionally moving under LockType, removed-ids.txt is the mechanism for recording that rename.
There was a problem hiding this comment.
Oh right, we could use:
.. raw:: html
<span id='thread.lock.acquire'></span>
Like we do elsewhere in the documentation.
_thread.LockType is a class (the type of lock objects), but was documented with the ".. data::" directive, so ":class:" cross-references to it cannot resolve against a py:class target. Switch the entry to ".. class::", move it next to the lock methods, and document acquire(), release() and locked() as methods of the class. Keep the old _thread.lock.* URL fragments working with raw HTML anchors.
343add6 to
1a8a3a8Compare
vstinner
left a comment
There was a problem hiding this comment.
LGTM. The LockType class doc is now rendered properly.
I'm not sure about the <span id='...'></span>. I would prefer that @StanFromIreland double check these additions.
StanFromIreland
left a comment
There was a problem hiding this comment.
That bit is correct, Victor.
vstinner
commented
Jun 2, 2026
Thanks @gaborbernat for the better doc! |
Thanks @gaborbernat for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13. |
Thanks @gaborbernat for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14. |
Thanks @gaborbernat for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.15. |
Sorry, @gaborbernat and @vstinner, I could not cleanly backport this to |
GH-150784 is a backport of this pull request to the 3.14 branch. |
GH-150785 is a backport of this pull request to the 3.15 branch. |
GH-150786 is a backport of this pull request to the 3.13 branch. |
…50784) gh-89554: Document _thread.LockType as a class (GH-150684) _thread.LockType is a class (the type of lock objects), but was documented with the ".. data::" directive, so ":class:" cross-references to it cannot resolve against a py:class target. Switch the entry to ".. class::", move it next to the lock methods, and document acquire(), release() and locked() as methods of the class. Keep the old _thread.lock.* URL fragments working with raw HTML anchors. (cherry picked from commit e37ce56) Co-authored-by: Bernát Gábor <gaborjbernat@gmail.com>
…50785) gh-89554: Document _thread.LockType as a class (GH-150684) _thread.LockType is a class (the type of lock objects), but was documented with the ".. data::" directive, so ":class:" cross-references to it cannot resolve against a py:class target. Switch the entry to ".. class::", move it next to the lock methods, and document acquire(), release() and locked() as methods of the class. Keep the old _thread.lock.* URL fragments working with raw HTML anchors. (cherry picked from commit e37ce56) Co-authored-by: Bernát Gábor <gaborjbernat@gmail.com>
) gh-89554: Document _thread.LockType as a class (#150684) _thread.LockType is a class (the type of lock objects), but was documented with the ".. data::" directive, so ":class:" cross-references to it cannot resolve against a py:class target. Switch the entry to ".. class::", move it next to the lock methods, and document acquire(), release() and locked() as methods of the class. Keep the old _thread.lock.* URL fragments working with raw HTML anchors. (cherry picked from commit e37ce56) Co-authored-by: Bernát Gábor <gaborjbernat@gmail.com>
_thread.LockTypeis a class (the type of lock objects), but the documentation marks it with the.. data::directive, so:class:cross-references to it cannot resolve against a py:class target.Switch the entry to
.. class::.Refs: gh-89554. Documentation-only change, so no
Misc/NEWSentry (skip news).This file is not covered by CODEOWNERS, so cc @vstinner, who reviews most
_threadchanges.