Dropping support for old Python versions

[srittau]

Since Python 3.8 is about to reach its end of life, maybe it's time to discuss (and write down) a general policy on how long we continue to support a Python version that has reached end of life.

Some historic data and discussion:

• We dropped support for Python 3.5 after about a month. (Drop support for Python 3.5 #4675) @JukkaL mentions:

The decision to drop 3.5 support in typeshed can be orthogonal to the decision to drop 3.5 support in mypy, I think.

• After previous discussion in Python 3.6 EOL (not before July 2022) #6189 we dropped support for Python 3.6 over 6 months after it reached end of life.
• After previous discussion in Drop support for Python 3.7 (not until January 2024) #10113 we dropped support for Python 3.7 about 6 months after it reached end of life.

Personally, I'm in favor of dropping support as soon as possible, ideally when the Python version reaches end of life. An obsolete Python version should really not be used anymore, and I have little sympathy for people who still do. It's also an increasing maintenance burden, as projects that we rely on drop support. Looking through the old issues above also showed increasing issues the longer we waited to drop support. Currently, #12711 needs to disable pyright checks for two third-party packages that won't check with Python 3.8 anymore, and we already dropped support for 3.8 in flake8-pyi (although that's on us). And we already have workload issues in typeshed, where any additional complications are not helping.

[AlexWaygood]

Thanks for opening the discussion. Broadly I agree with your perspective, though I don't really have a strong opinion either way here.

I agree that supporting older versions causes some additional complications for us, and that the complications have become more significant since we started allowing non-types dependencies for stubs packages. I also agree that we're stretched as a team right now.

However, I don't think the complications are too hard to workaround, and I'd prefer to prioritise the experience of our users.

What's unclear to me is how much of a benefit it really does have for our users to keep support for these older Python versions after they're end-of-life. If necessary, users can always pin to an older version of their type checker (or even use --custom-typeshed-dir and point to an older version of typeshed) if they still need stdlib stubs for older versions of Python.

I also agree that it's generally good to encourage users to upgrade to newer versions of Python.

[srittau]

What's unclear to me is how much of a benefit it really does have for our users to keep support for these older Python versions after they're end-of-life. If necessary, users can always pin to an older version of their type checker (or even use --custom-typeshed-dir and point to an older version of typeshed) if they still need stdlib stubs for older versions of Python.

That's a point I forgot to make, and which has been alluded to by me quoting Jukka above. Users will always be able to continue using older stubs/type checker versions. Also, these are development dependencies, not runtime dependencies, so it's also possible to update the development environment without affecting runtime compatibility. Overall I think the impact of us dropping support for old Python versions is small.

[JukkaL]

Note that mypyc is a bit of a special case -- dropping support for a Python version in stubs could cause mypyc to generate invalid code in some cases. Mypyc uses stdlib types to add runtime type checks.

My preference would be to keep supporting an EOL Python version for two or three months after the next Python feature release is out, so that we can ship a mypyc version that supports both the EOL Python and the newly released Python version. This gives mypyc users up to one year more time to drop support for the EOL version, in case they ship wheels compiled with mypyc. They wouldn't always be able to upgrade to the latest mypyc release, but that seems like a reasonable tradeoff if they want to support an EOL Python version. For example, we'd support 3.8 in typeshed for 2-3 months after 3.13 is out.

And as a random data point, Cython (which has a bunch of overlap with mypyc in target use cases) has a history of supporting EOL Python versions for some time.

[hauntsaninja]

Typeshed is basic infrastructure, so I think we should be conservative — within reason, we'd ideally be as conservative as our most conservative dependent, and six months seems quite reasonable.

I'm willing to compromise on some aspects of this:

• For third party stubs, I think it's fine to be more aggressive when upstream drops support for older Python
• If it's a maintenance burden, we can drop testing with old Python versions, but e.g. still keep the old sys.version_info branches around (if we're maintainer bandwidth constrained, this is actually less total work)

[Avasam]

I agree not to keep support for any more than 6 months (which matches our policy for obsolete stubs)

I agree with JukkaL about having a period of overlap between a recently EOL version and the newly released version, to help users in migration (this is less relevant for third-party stubs). Now the nice thing with the current release schedule, is that we should naturally get a few weeks of overlap (3.13 releases in ~ a week, 3.8 EOL at the end of the month)

If we're going to choose an arbitrary number, then may I suggest "after the next releases' first bugfix release"? Which currently seems to be ~ every 2 months. This totals in ~3 months after 3.8's EOL.

So keeping support for 3-6 months for the stdlib would be my suggestion.

---

• For third party stubs, I think it's fine to be more aggressive when upstream drops support for older Python
• If it's a maintenance burden, we can drop testing with old Python versions, but e.g. still keep the old sys.version_info branches around (if we're maintainer bandwidth constrained, this is actually less total work)

I agree that if keeping a certain 3rd-party stub's older Python version support around is especially painful, we could allow ourselves to drop that support sooner than whatever time span we land on.

Especially if, to srittau's point, we properly communicate to users in https://github.com/python/typeshed#package-versioning-for-third-party-stubs that they can just pin their stub to restore previous Python version support and that we don't recommended they themselves keep supporting EOL Python.

[srittau]

• If it's a maintenance burden, we can drop testing with old Python versions, but e.g. still keep the old sys.version_info branches around (if we're maintainer bandwidth constrained, this is actually less total work)

I disagree, it's still more work to keep the branches around. That said, branches are the least of our worries, the test infrastructure and dependencies are.

Here's a concrete proposal, based on the items in #12112. 2-3 months after release (January with the customary October release):

• Officially drop support by updating the documentation.
• Update the oldest_supported_python key in pyproject.toml, dropping support from 3rd party stub packages released after that.
• Remove support from our infrastructure scripts.
• Update stubtest allow lists.

After 5-6 months (usually around April):

• Remove branches.
• Remove obsolete stdlib modules.
• Replace typing_extensions imports.

[srittau]

Edit to the list: I've moved the allow lists, since by updating the test infrastructure, there's no need to keep the allowlists around.

[Avasam]

As a technical note, bumping the python version for Ruff should come with the "5-6 months" otherwise it'll catch obsolete branches and typing_extensions usage. Thankfully it doesn't follow the oldest_supported_python key in pyproject.toml

[eli-schwartz]

What's unclear to me is how much of a benefit it really does have for our users to keep support for these older Python versions after they're end-of-life. If necessary, users can always pin to an older version of their type checker (or even use --custom-typeshed-dir and point to an older version of typeshed) if they still need stdlib stubs for older versions of Python.

Pinning to an older version of mypy is what I currently do to typecheck with mypy --python-version 3.7 -- it's as a result an interesting experience since we then have a slight inconsistency with regard to new errors that users installing the latest mypy and running mypy get.

Maybe a mixed blessing since mypy 1.11 has teething issues with functools.partial handling, and due to the version pinning we have passing CI with stable type checking...

Using a custom typeshed dir sounds like an interesting notion that I might investigate. The immediate issue that comes to mind is that typeshed has no tags and it's not obvious how best to select that. Do I need to retrieve an old mypy 1.10.x release and tell mypy 1.11.x to use the copy of typeshed from mypy 1.10?

I also agree that it's generally good to encourage users to upgrade to newer versions of Python.

IMHO software should correctly state the version it depends on 🤷 bumping the minimum required version as part of deleting test coverage is an antipattern, bumping the minimum required version as part of introducing new code that requires the new version is reasonable but not every version of python introduces changes/features that require your source code to be rewritten. I was very happy to upgrade minimums from 3.6 -> 3.7 albeit it was a lot of effort to upgrade otherwise working end-to-end test infrastructure for "test minimum requirements". 3.7 -> 3.9 doesn't quite feel compelling. The fact that I personally use 3.12 is not topical to what others may use (and plenty of people are already unhappy we introduced code that is incompatible with python 3.6 "because RHEL" -- we offered to let them help maintain a RHEL compatible LTS and to their credit, a RHEL employee curated backports for several maintenance releases for that very purpose).

But that's our nonexistent burden to bear and no one else's.

[eli-schwartz]

If necessary, users can always pin to an older version of their type checker (or even use --custom-typeshed-dir and point to an older version of typeshed) if they still need stdlib stubs for older versions of Python.

Using a custom typeshed dir sounds like an interesting notion that I might investigate.

This does not work.

$ ./run_mypy.py --python-version=3.7 --custom-typeshed-dir=$PWD/typeshed/
Running mypy (this can take some time) ...
usage: mypy [-h] [-v] [-V] [more options; see below]
            [-m MODULE] [-p PACKAGE] [-c PROGRAM_TEXT] [files ...]
mypy: error: argument --python-version: Python 3.7 is not supported (must be 3.8 or higher)

[hauntsaninja]

Thanks for chiming in!

--custom-typeshed-dir isn't a solution we should generally recommend to users (although it is possible to make it work for expert users). There are semantics related to Python versions that are not captured in stubs that can get dropped. Type checkers can also be sensitive to changes in typeshed, mypy even patches typeshed in a location or two.

since we then have a slight inconsistency with regard to new errors that users installing the latest mypy

There's enough inconsistency between all type checker versions that we do generally recommend pinning the type checker for your project. It's unfortunate that counterfactually you'd have upgraded to latest, and without which your odds of mismatch between pinned and latest are increased. But it's worth setting up your contributing flows to pull in specific versions anyway.

I view typeshed's six month period as providing transition cover for projects that are fairly conservative or slow but broadly willing to drop support for end of life Python's, not as a long term support for an end of life Python. For instance, I don't think we'd be willing to still be supporting Python 3.7 right now (just for our own maintenance reasons — personally I don't think typeshed should really be in the business of "encouraging users to upgrade to newer versions of Python", which I take to mean willingness to drop support even if the cost of support was exactly zero)

[eli-schwartz]

--custom-typeshed-dir isn't a solution we should generally recommend to users (although it is possible to make it work for expert users). There are semantics related to Python versions that are not captured in stubs that can get dropped. Type checkers can also be sensitive to changes in typeshed, mypy even patches typeshed in a location or two.

Thanks for clarifying. I was afraid that might be the case. :) Pinning it is then.

It's unfortunate that counterfactually you'd have upgraded to latest, and without which your odds of mismatch between pinned and latest are increased. But it's worth setting up your contributing flows to pull in specific versions anyway.

I generally don't like proactive dependency pinning -- but never got around to hooking up lint workflows to work the same as the end to end integration tests, i.e. "mint a weekly docker container that installs the latest versions of all dependencies, IFF that latest set passes all tests. Then, run PR tests against the most recent CI image that successfully deployed".

Test dependencies are kept automatically up to date, and your commit logs record real changes that needed to be made. Support versioning is an exceptional event -- that's in part why, by design, we have no python dependencies other than CPython (even our one stdlib backport, tomllib, has a C++ subprocess.run() fallback).

It's unusual to need to say that contributors running updated versions of test dependencies, that hit an issue, are anything but an ordinary bug fix that will possibly even unstick the weekly redeploy.

[AlexWaygood]

personally I don't think typeshed should really be in the business of "encouraging users to upgrade to newer versions of Python", which I take to mean willingness to drop support even if the cost of support was exactly zero

FWIW that is not what I wanted to say when I used the phrase earlier above. I hoped it was clear that this wasn't where I stood when I said

I don't think the complications [of supporting EOL versions for some time] are too hard to workaround, and I'd prefer to prioritise the experience of our users.

But I guess this is my fault for tossing in a sentence like that without defining what I meant by "encouragement" in this context :-) I guess I'm not really sure what I did mean to say there; I'm happy to withdraw it.