Decide on a Python version support policy

[dstansby]

What needs to be done?

It would be good to decide and document which versions of Python to support. The two options here seem to be:

1. All currently supported Python versions (currently 3.8 - 3.12)
2. All Python versions supported by Scientific Python Ecosystem Coordination 0 (currently 3.10 - 3.12)

[dstansby]

I'm happy for either - I see the arguments for only supporting newer versions (https://github.com/UCL-ARC/python-tooling/issues/359#issuecomment-2077351878), but also don't think there would be much more burden in supporting older but-still-security-patched versions.

[samcunliffe]

Half-vote for keeping 3.9 🗳️. (I guess that's option 1.5 🙃 )

[dstansby]

I'm 👎 👎 having an ad-hoc approach where we decide a list of versions we support on a rolling basis, instead of following an existing policy that decides for us.

[samcunliffe]

~~Wait, 3.8 is EOL, no?~~

Nope. 3.8's EOL is 2024-10 so option 1 will become what I voted for very soon.

[paddyroddy]

I vote 2️⃣

[dstansby]

I'm coming round to 1️⃣ , because I don't think it is much more effort to support more Python versions, and we do work on some projects in ARC that aren't within the scientific python ecosystem (I'm thinking web projects, but maybe there's others?)

[dstansby]

Those advocating for 2️⃣ , what are your reasons?

[paddyroddy]

For me, a few reasons:

• The green reason, inevitably CI will have to run more
• Missing out on new features of the language - you'll get them eventually, but nice to get them quicker
• Missing out on potential speed gain, for example Python 3.11 was 10-60% faster than Python 3.10 - again you'll get it eventually, but once the min version is 3.11 then you benefit quicker
• Supported by big communities, SPEC 0 is endorsed by ipython, networkx, numpy, scikit-image, scipy, xarray, zarr
• New libraries may not be built to support older Python versions, say 3.10 was the newest one when it came out. It may not support older versions.

[dstansby]

The green reason, inevitably CI will have to run more

If you do the numbers I think this is very small number compared to e.g., flying to conferences or on holiday or embodied carbon of hardware or electricity usage of a large simulation code. I once etimated that Matplotlib uses ~25 kg/month [png link], and they must be running orders of magnitude more CI than us.

I buy the rest of the arguments though. I think @matt-graham was also pro SPEC 0, so perhaps we give @samcunliffe a bit to explain

Half-vote for keeping 3.9

from above, and then unless there's a compelling reason go with SPEC 0?

[samcunliffe]

My vote was a soft 1, but very soft. Mostly web/dashboard/other.

If the majority want 2, let's go for it. Less GHA minutes also has cost implications if our users have nonpublic repos. And 🌱 is a good argument.

[dstansby]

👍 I'll leave this open until we document the decision, and merge https://github.com/UCL-ARC/python-tooling/pull/360