gh-134895: Add sphinx-codeautolink to doc build #134896
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds the https://sphinx-codeautolink.readthedocs.io/ Sphinx extension to the documentation build process. In their own words, it
In my opinion, it is quite helpful for documentation readers to be able to immediately jump from e.g. tutorial code using
logging.getLogger
(<-- points to the PR doc build that shows the linking) to its reference description.A bit of discussion has happened in https://discuss.python.org/t/add-the-sphinx-codeautolink-extension-to-doc-build-process/80814, back when the extension was not as robust and featureful as nowadays.
As said there, the styling of these extra links can be as unobtrusive as we want them.
Code examples that are parseable and self-contained (i.e. have all their imports) will have clickable objects.
Examples that are made up of parts that build on each other can also be supported with some extra markup (not part of this PR).
Missing imports can be annotated "invisibly" (not part of this PR).
Also, in the current state of the documentation, not all code examples that could be parseable actually are.
#133906 would fix a number of these.
Other examples would benefit from using
.. code-block::
with an explicit language set instead of::
so that special handling forpycon
(clean_pycon
) could kick in. Right now, these places are producing a warning that is handled viasuppress_warnings
.Speaking of
suppress_warnings
, it containsconfig.cache
because ofWARNING: cannot cache unpickleable configuration value: 'codeautolink_custom_blocks' (because it contains a function, class, or module object) [config.cache]
, which is indeed set to the functionclean_pycon
.📚 Documentation preview 📚: https://cpython-previews--134896.org.readthedocs.build/