Support all official Python version

[fcollonval]

repo-review requires Python >= 3.10. This is a bit annoying for older projects/installation.

What are the technical reasons for not supporting all officially supported Python version (meaning >=3.8)?

Xref: jupyterlab/jupyterlab_server#451

[danielballan]

I will let @henryiii comment on repo-review specifically, but some useful context for this discussion is SPEC 0.

[henryiii]

Ahh, SPEC 0. Quick bit of context: personally, I don't like SPEC 0 and it's 36 month support window for CPython (or NEP 29, which was marginally better at 42 months). I've held that it serves to drive a wedge between "scientific python", and "official Python", that is, everyone else in the world. NEP 29 was born out of necessity when official EoL supported a single version of Python for a ludicrous 10 years. But now two things have changed: No version of Python has an extra large support window, and Python releases are now yearly. The official "full support" window of Python was just bumped from 1.5 years to 2 years starting with 3.13, as well, so I have the faintest glimmer of hope it might be reconsidered, but I doubt it. I asked several times to part of the discussion last year at the scientific-python summit, but was excluded (and horrified to see the difference with official Python increased rather than decreased!)

On linux, more people use Python 3.8 than any other single version, 3.8 + 3.9 are used more than than 3.10-3.13.0b1 combined. More people use 3.7 than 3.11 and 3.12 combined. More people use 3.6 than 3.12. Only about 34% of users are using 3.10 and newer.¹ I believe the situation is drastically better on macOS and Windows, but don't have the downloads as handy for those.

The core idea, and the reason it works at all, is that it applies really well to stable libraries. If you have a stable library, like NumPy, SciPy, etc, then it really doesn't matter that you are getting an older version if you have an older Python - most of the time. "Dropping support" does't really mean that, it means "no longer add new features and maybe bug fixes". It also means "no accidental breakage" - NumPy was even considering dropping 3.9 from NumPy 2.0 (NEP 29/SPEC 0 don't say much about a long release process that spans a drop date) specifically to reduce breakage. Libraries that have dropped 3.9 may have to make a patch release to fix 3.9 users (which is mostly just a handful of the SPEC 0 adopting libraries).

This is generally true; a consistent support window is better for users, even ones on the "dropped" versions. That's why SPEC 0 exists, and it's why the clash with official EoL is annoying to me. But dropping versions has big benefits, especially for open source software; easier maintenance, fewer binaries, less technical debt, can use new API when designing new features (like positional only arguments were adopted in NumPy's new API), can keep C-API clean, etc. The downside is that it's much harder to depend on "scientific" libraries in a non-scientific context now, as you have to support a wide range of older releases.

SPEC 0 is a bit less annoying to me personally now that it's 3.10+, as I love Python 3.10. And I'm okay to (now) claim that we are following SPEC 0 here, even though it was actually 3.10+ well before SPEC 0 dropped it, more on that in the answer below.

Footnotes

1. Source: https://mayeut.github.io/manylinux-timeline/ under consumer statistics. And I think this basically means people are using their distribution to get Python and taking whatever it gives them. ↩

[henryiii]

See above for random rambling about SPEC 0. Now on to "technical reasons", which is two-fold; there are two libraries here; repo-review (the check runner) and sp-repo-review (these checks). I'll start with repo-review:

I actually did try to extend repo-review back to 3.9. I worked through a bunch of things; there are some match statements and quite a few usages of Python 3.10 features, but I think it would be doable if someone persevered longer than I did. I gave up at some point, but would be happy to provide the branch (if it's not discoverable) if someone wants to pick it up, and I would accept a good PR. 3.8 would be harder, since the core of repo-review is the topological sorter introduced in 3.9. But there's probably a back port that could be used. There are also a few other 3.9 features, but the topological sorter is the big one at the core of repo-review.

The reason I wasn't very dedicated in my branch is the most popular plugin, sp-repo-review, is very unlikely to support 3.9. The checks are almost all built around pattern matching, and making this work on older versions will make the checks uglier and harder to maintain. I think I'd stick by SPEC 0 (now that it is 3.10+) here - no 3.9 for sp-repo-review. If someone made the PR, and it looked clean enough, I might change my mind, but no promises. It would add technical debt that in a bit over a year won't matter anyway when official EoL for 3.9 hits.

This is more noticeable here that in the usual libraries that follow SPEC 0 because there never was a 3.9 release of these. (I wrote the original some point shortly after pattern matching came to Python in 3.10, probably before the release of 3.11).

IMO, repo-review and similar libraries (I do the same thing with flake8-errmsg¹, it's also 3.10+) are developer focused, and developers should not be using old Python's as their primary drivers. You will get huge benefits upgrading (like better error messages, or even a new REPL in 3.13). And the system Python that ships on Linux distributions is not intended for users, it's there to support other apt/yum packages. If you are developer, hopefully you know how to install and use a proper Python. Hatch, PDM, Rye, and pyenv all provide easy ways to get a Python that is not tied to your system. And there's docker, etc.

Also, it's totally okay to skip this check (SKIP var in pre-commit). Unless you are messing with configuration, sp-repo-review is extremely unlikely to change in a commit. That's why it was initially designed to be run from WebAssembly, the pre-commit integration came later because people wanted it.

Footnotes

1. Ruff adopted it so that's the path forward for users wanting to lint on <3.10 for flake8-errmsg. ↩

[henryiii]

I just checked my old stashed 3.9 attempt, and after removing the match statements (4 usages), I ran into:

• kw_only dataclasess require 3.10+ (3 usages)
• Unexpected keyword argument "group" for "entry_points" (4-ish usages)

[fcollonval]

Thanks for the detailed answer @henryiii

From it, I don't think it is indeed worth the trouble of increasing Python version compatibility. As you mentioned, developer can upgrade their Python version.