bindings: python: when do we EOL python 3.9 (and onwards)?

[vfazio]

Per https://devguide.python.org/versions/ Python 3.9 goes EOL this October (2025).

Maintaining the bindings for 3.9 is not overly difficult at this point since we don't do anything super advanced in the python layer around the C library.

The biggest thing is probably cleaner typing syntax... I don't think there's anything core we're going to benefit from off the top of my head.

What I don't have a good sense of is how to balance the non-EOL Python versions vs distro support vs our published support range. RHEL 9 ships 3.9 but isn't EOL until 2027. By then, python 3.16 will be out.

Dropping older Python just means newer versions of python can use newer binding releases. Older python versions can still use any published package that supports its version, but if there are fixes in newer bindings, the older packages will not receive them.

Some distros (like RHEL) provide alternate system packages with newer python. Otherwise, tools like uv or pyenv help with deploying new versions of python onto systems shipped with a "stale" version, however, some users may be locked into a specific version for legacy/corporate purposes, meaning when a dependency stops being supported for their version, a lot of work may need to go into updating the entire codebase and re-validating on a new python version.

The hurdle to supporting the larger version range is simply testing. There is no CI driven automated testing that I see to make sure all tests run across all supported python versions. I've tested some of my patches by hand on 3.9 and just assumed if it works there, it will work on future versions, but I haven't taken the time to do this for every patch for all versions.

I can maybe make a CI test suite on my fork that can make this a little less arduous and take the guess work out of if everything works like we expect.

Regardless, we probably want to establish policies about when we cut off old versions of Python from the bindings.

[brgl]

Ok so I admit I'm not quite clear on why we need to drop support for v3.9 if nothing changes in the libgpiod code? Is there anything we can actually make better if we require a more recent version?

[vfazio]

Yea, sorry. Like I mentioned in my email I was just brain dumping.

Maintaining python 3.9 support in perpetuity will eventually become a headache because the tools we use may actually stop supporting that version. So there's a real chance that tools like mypy and cibuildwheel stop supporting that version, meaning we're locked into older versions of those tools.

As an example:

• https://mypy.readthedocs.io/en/stable/changelog.html#remove-support-for-targeting-python-3-8

Being locked into an older version of mypy probably won't be a big deal, but being locked out of cibuildwheel means we may have to make wheel generation a two step process, build older wheels with older cibuildwheel and newer wheels with a newer version.

The next hurdle, beyond the dependencies, would be to support deprecations in subsequent versions of CPython.

If some standard module we're using in the bindings gets deprecated in a new version, we have to find a way to continue to support the old version as well as the new version, which may mean littering the code with version checks. Changes to the CPython C API could also drive similar behavior.

Subsequent to all of those would be things like:

• Simplifying type annotations (this is mostly just a visual nicety)
• Being able to use new semantics/features as they become available

The worst case scenario I can think of right now is a new version of Python that we want to support drops support for parsing "old style" type annotations. I think that would really force our hand.

This may be better illustrated with a visual, but really, dropping Python 3.9 and subsequent versions as they go EOL (or some time thereafter) should not be a big deal.

The sdists and wheels published on PyPI will still be usable by users that need the bindings for those versions.

The only downside is that users may not get fixes to the bindings that we make after dropping the old versions... meaning they would need to migrate to a newer version of python to get those fixes or work around the "bug" in the bindings within their own codebase.

This is probably one of the biggest reasons i need to get off my ass and fix #148 so that it's included well before we entertain the idea of dropping python 3.9.

I think it's reasonable to support the python 3.9 until it's clear that support for it even as a legacy version is waning. The clear indicator would be projects like mypy/ruff/cibuildwheel dropping support... so that means probably ~1 year after the version goes EOL.

[brgl]

I think you've become the unofficial maintainer of the python bindings by now, I'll defer to your judgement here. I'm fine either way. I really like the type naming improvements that came with v3.10 so even for that I'm perfectly fine with dropping support for v3.9.

[vfazio]

Ran a quick query to see what our download stats look like since Jan 1 2025

3.9 is dwarfed by other versions. I've gone over my reporting quota at the moment so I can't differentiate between sdist and wheel.

I have a few enhancements/cleanups pending in #149. I think once that series, or a subset of it, lands, we can entertain the idea of bumping the minimum required version and updating the type syntax. We can schedule that work around the end of the month, in line with https://endoflife.date/python

Users using older versions of python will still have access to older versions of the bindings and they can pin to the version they wish to work with, but they will have to deal with any quirks therein.

Support requests can be limited to 3.10+ once we make the change.