-
-
Notifications
You must be signed in to change notification settings - Fork 29.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-46879: Fix incorrect sphinx object names in doc #31615
bpo-46879: Fix incorrect sphinx object names in doc #31615
Conversation
API members documented in sphinx have an object name, which allow the documentation to be linked from other projects. Sphinx calculates the object name by prefixing the current module name to the directive argument, e.g: .. module:: foo .. function:: bar.baz becomes foo.bar.baz. Since these anchors aren't displayed in the documentation, some mistakes have crept in, namely the Python stdlib documentation currently contains the objects: * asyncio.asyncio.subprocess.DEVNULL * asyncio.asyncio.subprocess.PIPE * asyncio.asyncio.subprocess.STDOUT * asyncio.asyncio.subprocess.Process * multiprocessing.sharedctypes.multiprocessing.Manager * xml.etree.ElementTree.xml.etree.ElementInclude This commit fixes this by making use of the :module: option which without an argument makes sphinx take the directive argument as is for the object name (avoiding the prefixing of the current module name that led to these broken object names).
How does backporting work? I'd like this fix to be backported all the way to 3.7. |
The development process is documented here: https://devguide.python.org/devcycle/ At the moment, 3.10 and 3.9 receive bugfixes, 3.8 and 3.7 only security fixes. |
Thanks @not-my-profile for the PR, and @ambv for merging it 🌮🎉.. I'm working now to backport this PR to: 3.9, 3.10, 3.11. |
GH-92974 is a backport of this pull request to the 3.11 branch. |
GH-92975 is a backport of this pull request to the 3.10 branch. |
API members documented in sphinx have an object name, which allow the documentation to be linked from other projects. Sphinx calculates the object name by prefixing the current module name to the directive argument, e.g: .. module:: foo .. function:: bar.baz becomes foo.bar.baz. Since these anchors aren't displayed in the documentation, some mistakes have crept in, namely the Python stdlib documentation currently contains the objects: * asyncio.asyncio.subprocess.DEVNULL * asyncio.asyncio.subprocess.PIPE * asyncio.asyncio.subprocess.STDOUT * asyncio.asyncio.subprocess.Process * multiprocessing.sharedctypes.multiprocessing.Manager * xml.etree.ElementTree.xml.etree.ElementInclude This commit fixes this by making use of the :module: option which without an argument makes sphinx take the directive argument as is for the object name (avoiding the prefixing of the current module name that led to these broken object names). Co-authored-by: Łukasz Langa <lukasz@langa.pl> (cherry picked from commit 2cdd57f) Co-authored-by: Martin Fischer <martin@push-f.com>
API members documented in sphinx have an object name, which allow the documentation to be linked from other projects. Sphinx calculates the object name by prefixing the current module name to the directive argument, e.g: .. module:: foo .. function:: bar.baz becomes foo.bar.baz. Since these anchors aren't displayed in the documentation, some mistakes have crept in, namely the Python stdlib documentation currently contains the objects: * asyncio.asyncio.subprocess.DEVNULL * asyncio.asyncio.subprocess.PIPE * asyncio.asyncio.subprocess.STDOUT * asyncio.asyncio.subprocess.Process * multiprocessing.sharedctypes.multiprocessing.Manager * xml.etree.ElementTree.xml.etree.ElementInclude This commit fixes this by making use of the :module: option which without an argument makes sphinx take the directive argument as is for the object name (avoiding the prefixing of the current module name that led to these broken object names). Co-authored-by: Łukasz Langa <lukasz@langa.pl> (cherry picked from commit 2cdd57f) Co-authored-by: Martin Fischer <martin@push-f.com>
GH-92976 is a backport of this pull request to the 3.9 branch. |
API members documented in sphinx have an object name, which allow the documentation to be linked from other projects. Sphinx calculates the object name by prefixing the current module name to the directive argument, e.g: .. module:: foo .. function:: bar.baz becomes foo.bar.baz. Since these anchors aren't displayed in the documentation, some mistakes have crept in, namely the Python stdlib documentation currently contains the objects: * asyncio.asyncio.subprocess.DEVNULL * asyncio.asyncio.subprocess.PIPE * asyncio.asyncio.subprocess.STDOUT * asyncio.asyncio.subprocess.Process * multiprocessing.sharedctypes.multiprocessing.Manager * xml.etree.ElementTree.xml.etree.ElementInclude This commit fixes this by making use of the :module: option which without an argument makes sphinx take the directive argument as is for the object name (avoiding the prefixing of the current module name that led to these broken object names). Co-authored-by: Łukasz Langa <lukasz@langa.pl> (cherry picked from commit 2cdd57f) Co-authored-by: Martin Fischer <martin@push-f.com>
API members documented in sphinx have an object name, which allow the
documentation to be linked from other projects. Sphinx calculates the
object name by prefixing the current module name to the directive
argument, e.g:
.. module:: foo
.. function:: bar.baz
becomes foo.bar.baz. Since these anchors aren't displayed in the
documentation, some mistakes have crept in, namely the Python stdlib
documentation currently contains the objects:
This commit fixes this by making use of the :module: option which
without an argument makes sphinx take the directive argument as is
for the object name (avoiding the prefixing of the current module
name that led to these broken object names).
https://bugs.python.org/issue46879