Doc: Avoid error lexing multiprocessing docs code block on Pygments 2.15.0#103421
Uh oh!
There was an error while loading. Please reload this page.
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.
Due to the changes in how tracebacks are lexed in Pygments 2.15.0 (pygments/pygments#2226 and pygments/pygments#2329 ), the following code block in the multiprocessing docs:
cpython/Doc/library/multiprocessing.rst
Lines 455 to 472 in c3cd3d1
results in a docs build error when attempting to lex the code for syntax highlighting and other features:
due to pygments apparently attempting to parse the traceback, which fails. This was reported in pygments/pygments#2407 , but unless and until that is fixed, we need to unbreak the docs build.
Note that the fix will need to be backported as far as 3.7 to fix the docs CIs/builds there (given that I confirmed Pygments 2.15 should be picked up even that far back), otherwise any future PRs/commits on those branches will also run into the error.
Ideally it would be nice to avoid breaking syntax highlighting, the
>>>button, selection of only the user-entered text and other custompyconfeatures on the whole block, which could be done by splitting it into two code blocks, one with the code and one with the output. However, this would be more complex and complicate backporting, since the error is apparently different in different versions and there were other changes in between.We could also pin to Pygments 2.14, but at the moment its unclear if they will fix it upstream (since its an extremely narrow corner case and unclear how they would distinguish it from valid cases), so it might block adoption of current and future Sphinx and pygments versions all for one single code block. This also would probably need a separate fix on the docs build server which is onerous to touch.
Therefore, I've just changed that block to use plain
textas the lexer, which is slightly less ideal but is the simplest all-around solution for now, and can easily be changed/reverted later if it does get fixed upstream. Conveniently for the purpose, it also discourages the user from actually trying the example, which will hang their Python interpreter.