When to drop support for python 2.7 as host tooling?

[jepler]

I was looking at ci.sh and reminded that in several places, the CI build takes care to use python 2.7 seemingly just to ensure compatibility with old versions.

Some scripts have headers that declare they work back to 2.6 and 3.3, which is certainly not being tested.

Are there known users depending on these old python runtimes? Is there some reason not to bump the minimum to, say, 3.9 (the oldest Python version not end-of-life'd at the time of writing)? Supporting 3.9 would preserve support for debian oldstable & ubuntu oldlts; and installing newer python versions for development is easier than ever with modern tools like uv.

[Josverl]

I would agree with dropping CPython 2.x support , and anything else older than CPython 3.4.

For the 3.4 - 3.9 part there may need verification with the CPython compatibility tests, although AFAIKT they are run with the default python version on the runner.

In a quick scan I see a number of jobs in the CI that declare python versions,
of there only the macos would need updating

Workflow	Job(s)	Python Version Specified
ports_unix.yml	settrace, settrace_stackless	3.11
ports_unix.yml	macos	3.8
ports_windows.yml	build-mingw	3.11

There are likely additional dependencies in tools/ci.sh and some of the toolchains

• 32 bit builds
• nanbox

I do not know if or how these can be brought to python 3.x

[jepler]

Any particular reason you suggest 3.4?

[sosi-deadeye]

Any particular reason you suggest 3.4?

https://docs.micropython.org/en/latest/genrst/index.html#micropython-differences-from-cpython

MicroPython differences from CPython¶

MicroPython implements Python 3.4 and some select features of Python 3.5 and above. The sections below describe the current status of these features.

Only Python versions that are not yet EOL should be supported: https://devguide.python.org/versions/

[Josverl]

The reason is that MicroPython is 3.4 and some features from newer versions.
So while I agree that we can't support a version that is not supported by CPython, that leaves the uncanny space between 3.4 and Cpython.

That space is getting wider by a version a year, and even Cpython differences only go to V3.10 at the moment.
So apart from deprecation, a clear strategy is needed in how to address that.