| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Running sphinx-build in nit-picky mode, like:
sphinx-build -n . build/html/
or:
make html SPHINXERRORHANDLING=-n
gives tons warnings. ~8k of them at the time of writing.
Most of them are innocent, like using :const: while referring to a constant defined in another file, or using :meth:`__init__` to speak about the concept of an init method.
The fall in several cases:
I don't have statistics (yet) on the distribution for the 4 previous cases.
For the innocent usages of rst markers, there's two fixes:
My question is: should we try to fix all warnings so we can easily spot typos at build time?
I tried to see if some typo would have been avoided by the nit-picky mode by reading a few pages of WARNINGS and found just one: read1 instead of read in bz2.rst.
| Back | FazBrowse Home | New Git URL |
Activity
encukou commented on Jan 17, 2023
See also: https://discuss.python.org/t/broken-references-in-sphinx-docs/19463
IMO, we should fix these. Many are actual issues in the documentation.
Here's a proof-of-concept GH Action that complains about nitpicks in changed files only: encukou@e97d91f
Feel free to take it, I don't think I'll have time for this soon.
CAM-Gerlach commented on Jan 17, 2023
Yes, definitely; I've been gradually helping on the docs I've/we've touched anyway, though it is a long term project. I've found a number of things that were undocumented, as well as a number of other real issues through that, e.g. on the sqlite3 module that Erlend and I fixed.
I'd argue neither is exactly innocent:
There's a third, much simpler and better fix. If the link isn't desired, every Sphinx cross-reference role supports prepending ! to prevent Sphinx from trying to resolve the reference, which avoids both the warning and the (very slight) build-time lookup cost, while preserving both all the information in the source, and the formatting in the output (since the formatting of named roles and regular literals is not the same, at least in our current theme), while being easier than both (just add one character). So, you could just do:
:const:`!IGNORECASE`
pythongh-101100: Fix sphinx warnings in `enum` module
sobolevn commented on Jan 18, 2023
I've sent an example PR with the fix for enum module: #101122
The dev experience was plesant, because on the second run sphinx only rebuilds (and warns about) changed files:
CAM-Gerlach commented on Jan 19, 2023
As a general note of caution, especially when submitting PRs fixing these sorts of widespread and potentially nitpicky (heh) docs defects, especially when in cases like this there are a number of different possibilities to handle each warning instance, we should take care to avoid the folly of large "omnibus" PRs (as Guido likes to call them) and take care to consider each specific change we're making holistically, and ensure that we're picking the approach that best serves the reader in for each specific context, as opposed to just applying one type of fix mechanically to all instances, or even worse arbitrarily picking one or another each time without careful thought and consideration that might fix the warning but be an overall regression.
Otherwise, if we're too focused solely on the narrow objective of getting rid of the warnings by whatever means, as opposed to the broader goal of improving the overall quality of the docs, we risk both doing exactly the opposite of the latter, and consuming the limited time and churn budget of core developers and other reviewers on changes with little or even negative practical benefit.
encukou commented on Jan 19, 2023
That's the reasoning behind teaching the CI to only warn, and only on changed files.
gh-101100: [Enum] Fix sphinx warnings in docs (GH-101122)
pythongh-101100: [Enum] Fix sphinx warnings in docs (pythonGH-101122)
[3.11] gh-101100: [Enum] Fix sphinx warnings in docs (GH-101122) (#10…
hugovk commented on Feb 21, 2023
To enable this, it would be really useful if Sphinx had more granular config for the warnings/errors, similar to Flake8.
For example, we could enable nitpicky only for certain directories and files, and expand as more are cleaned. And possibly in combination with an exclude option.
Similarly, we may only want to enable/disable nitpicky for certain classes of warnings/errors.
That would allow us to iteratively fix things, and keep them fixed.
cc @AA-Turner
pythongh-101100: Fix Sphinx warnings in decimal module
hugovk commented on Feb 21, 2023
PR to fix 113 warnings in the decimal module: #102125
CAM-Gerlach commented on Feb 22, 2023
Yeah; you can silence warnings for particular names, but not in particular files, which would IMO be much more useful. Besides just incrementally fixing these issues, it would also be very useful to potentially keep permanently for What's New and Changelog pages (other than those for the current feature version in a particular branch) as those will naturally drift out of date over time. I believe I mentioned this on a Sphinx issue somewhere at some point semi-recently, but if I did I can't seem to find it now.
timobrembeck commented on Feb 24, 2023
Does anybody have an opinion on the docstring-side of matters? In other words, should the docstrings inside the Python source code also comply to Sphinx's nit-picky mode? (see e.g. #100989)
316 remaining items
StanFromIreland commented on Oct 11, 2025
I can create the issue tomorrow and transfer open issues.
You need to be a member of the “maintainer community” to view it: https://maintainers.github.com/auth/signin
picnixz commented on Oct 11, 2025
Thank you, I'll try to join the community to see the issue.
AA-Turner commented on Oct 11, 2025
Again, I don’t think we need a new issue (Stan: please do not create a new one).
This is a GH bug, fundamentally, which will be fixed at some point.
A
StanFromIreland commented on Oct 11, 2025
I agree it is a GH bug, though I think there is one problematic part in your observation:
This issue may be complete by the time that point arrives, why should we accept this bug? (I’ll wait for consensus before opening a new issue)
picnixz commented on Oct 11, 2025
I think it's fine to wait. I just wanted to know whether it was known or not. I don't mind keeping the same issue until it's fixed.
LamentXU123 commented on Oct 13, 2025
I'm fond of creating a new issue here. We've got around 57 docs remaining to fix (see /Doc/tools/.nitignore). Only 2/5 of this issue is completed and it is hard to trace comments on this issue now since it is flooded by related PRs. I think a new issue will be good for us to discuss on this without clicking 1805 remaining items, load more on the github page.
StanFromIreland commented on Oct 13, 2025
The are 51 entries in the file, on main?
LamentXU123 commented on Oct 13, 2025
Correct. I'm not catching the main branch since the issue is proceeding so fast.
This issue is indeed moving fast now, good. I literally think I can fix one doc per day, so just to remain the comments not to be flooded I think we can open a new issue here.
Abhi210 commented on Oct 16, 2025
Hello, So, I was looking at the warning:
c:identifier reference target not found: wrapperbase on line 27 of c-api/descriptor.rst
I modified the descriptor.rst to include the following line at the bottom of that file:
This succesfully removes the warning. However, this adds a link to the wrapperbase when rebuilding the html files. I tried using ``wrapperbase`` or !wrapperbase. However, the warning was still present. Is it Ok if we use the above descriptor for the wrapperbase? Or, is there any other method for removing the warning? I am sorry that I was not able to read the comments (There are 1800+ comments). Thankyou!
LamentXU123 commented on Oct 16, 2025
AFAIK, The reference is in the attr line, so ! and inline-codeblocks would not work.
+1 on this. I think it's ok to add one so the reference would point here. Thank you.
Ah. I still think we need a new issue here. cc @StanFromIreland
serhiy-storchaka commented on Jun 20, 2026
This issue is unmanageable. You cannot find what PRs were added, what is their status, and what was the original PR of the backport. I suggest to close it and open a new PR.
Also remember that fixing Sphynx warning is not a goal. They are symptoms of other issues, and we should fix the original cause, even if this will take tears.
StanFromIreland commented on Jun 20, 2026
@serhiy-storchaka, this was discussed above and decided that we don't need a new issue: #101100 (comment)
JelleZijlstra commented on Jun 21, 2026
I couldn't even read the comment linked by @StanFromIreland before clicking "Load more" half a dozen times. To make it easier (for now, until this comment goes past the fold), it's this comment by @AA-Turner:
I think this issue has served its purpose and this page is no longer workable. Let's open a new issue for any followup work.
hugovk commented on Jun 22, 2026
Agreed, we can do an issue per feature release, like we've done for improving import times:
StanFromIreland commented on Jun 22, 2026
I've created a meta issue for this, #151940, and sub-issues to avoid repeating the mistakes here ;-)