Repository navigation
[BUG] Incompatibility with pygments 2.21.0 #4209
Description
Activity
Patch updating pygments and the tests: https://gist.github.com/mdaniels5757/d2d48e8a5478b7b875b454b1237d3874 (I'd make a PR if I could.)
- added a commit that references this issue
on Aug 23, 2026 Independent verification of the patch linked above, on current
main(9d8f9a3), with a fresh clone and a small venv:- Pygments
2.21.0:pytest tests -q→ 8 failed, 948 passed, 25 skippedtest_card.py::test_card_rendertest_markdown.py::test_inline_code_in_table_cellstest_syntax.py::{test_python_render, test_python_render_simple, test_python_render_simple_passing_lexer_instance, test_python_render_indent_guides, test_option_no_wrap, test_syntax_highlight_ranges}
- Pygments
2.19.2on the same checkout: 956 passed, 25 skipped — so this is isolated to the Pygments upgrade, not a Rich change. - Pygments
2.21.0+ the gist patch applied (git applycleanly): 956 passed, 25 skipped.
What actually changes: the Python lexer now tokenises
iter,next,boolandStopIterationas builtins, so the Monokai style paints them38;2;166;226;46instead of the plain foreground. I stripped the escape sequences from the old and new expectations and compared the visible text: apart from those colour codes, the rendered text is unchanged, so the refreshed expectations are not hiding a rendering regression.Two notes for whoever lands this:
- The gist's
poetry.lockwas regenerated with Poetry 2.4.1; besides the Pygments entry it rewrites the generator header and somepython-versionsfields. Re-resolving with the Poetry version this repo uses would keep the lock diff to Pygments only. - The alternative is to leave the constraint alone and make the affected tests tolerant of the lexer's builtin set. That hides the change rather than documenting it, so the constraint bump plus refreshed expectations looks better to me.
Rich's AI policy asks for a maintainer-approved solution before an AI-generated PR, so I have not opened one. If the constraint bump is the route you want, say so here and I will send a PR —
pyproject.toml, refreshed expectations,poetry.lock,CHANGELOG.md, PR template filled, AI assistance disclosed. Patch credit belongs to @mdaniels5757.- Pygments
Independent verification...
Thanks.
The gist's poetry.lock was regenerated with Poetry 2.4.1; besides the Pygments entry it rewrites the generator header and some python-versions fields. Re-resolving with the Poetry version this repo uses would keep the lock diff to Pygments only.
This is false, the python-version field changes are because of pygments (https://github.com/pygments/pygments/releases/tag/2.20.0), not the poetry version.
Rich's AI policy asks for a maintainer-approved solution before an AI-generated PR, so I have not opened one. If the constraint bump is the route you want, say so here and I will send a PR — pyproject.toml, refreshed expectations, poetry.lock, CHANGELOG.md, PR template filled, AI assistance disclosed.
(emphasis added)
I assume you will not, for the same reason I haven't: PR creation is restricted. :)
Presumably @willmcgugan will look at this when he returns to this repo. I will be happy to turn my patch into a PR (adding changelog and contributor entries) should he so desire.
Correction accepted, and I checked rather than assuming: Pygments 2.20.0's own release note says "Drop Python 3.8", which is what flips the
pygmentsentry topython-versions = ">=3.9", and the[metadata]line is the lock catching up with rich's ownpython = ">=3.9.0". Both come from dependency/project metadata, not from the Poetry version — so scratch that point. The only genuine Poetry trace is the generator header (2.1.3→2.4.1), which is cosmetic and certainly not worth a re-resolve.The verification in my first comment stands: 8 failures with 2.21.0, clean with 2.19.2, and the patch green with 2.21.0. If @willmcgugan wants the constraint bump, I will send the PR; if he would rather it came from you, that is fine by me and I will not duplicate it.
I'm updating pygments to 2.21.0 in Fedora Linux and some of the tests of rich fail:
I cannot paste the output here because it's too long, thanks to the large diffs.