How backwards compatible with older Python versions should a library/tool be?

Python had quite a number of real useful improvements in version 3.8, up to recent 3.10.
However, when implementing a library/tool I am a bit concerned about what the implications may be of basically forcing users to use a rather recent version of Python if they want to use the library.
As I have been a Java developer in the past, this is something that always was of extreme concern – there are still tons of machines around where people run Java 8 (released 2014) or even older.

However I do not have a good feeling about how much of a concern this may be with Python - it seems installing a newer Python into a new environment version is easy and should not be a problem at all.

So what remains are situations where a user wants to use my library together with one that is not forward compatible with a newer Python version and requires some old version (e.g. 3.4 or 3.6). How common is this in Python? Should a library developer be worried about that?

If you want to be “safe-enough”, find a package/library that is common and support the same versions they do – pytest comes to mind (mostly because my libraries support 2.7 and 3.3+, and pytest only support 3.5 (3.6) +.

If you really want to use the latest features, and aren’t worried about other potential users, then support the last couple releases.

If you’re just plain stubborn (or have to for other reasons), support 2.7 and 3.3+. :wink:

1 Like

Well, one guideline would be to have a look at Python’s own rules for release
and support
- Python 3.6 just released end of life last December. Unless you have a specific user in mind, that seems a reasonable minimum to require.

For library changes and additions, often there’s a backport on PyPI you can use by wrapping the import in a try-except. Even for syntax changes you could use eval() or a conditional import to avoid it running on old versions.

1 Like

That’s a question only you can answer. The answer depends on what you hope to get out of this library. Do you prefer getting more users, or less work?

Its your library. If you want to support Python all the way to version 1.5, you can, but it will require a lot of work. Really a lot of work.

(For my sins, some years ago I was supporting back to Python 2.4. I tried to support 2.3, but it was just too painful.)

The more versions you support, the more users your library might attract. At some point the extra effort required to support version X.Y is not worth the number of users you will gain.

Or maybe you don’t care about attracting more users, if your library is published on a “take it or leave it” basis, then you can support whatever version of Python you personally use and forget everything else.

This is not a technical question (although we can help on the technical question of how to support multiple versions), it is a question about your values. How much do you value supporting old versions?

By the way, please don’t under-estimate the difficulty (some) beginners to Python have with installing multiple versions of the interpreter, or even upgrading the one version of the interpreter. Yes, experienced Python coders can easily run eight versions of the interpreter on the one machine, but lots of people find it hard to even install one version, let alone two.

(One side-effect of popularity of a language is that your users have a much bigger range of competency and skill, including “next to zero”.)

3 Likes

One factor to consider is that Ubuntu (one of the most popular desktop and server Linux distributions) 18.04 uses Python 3.6, and Canonical (Ubuntu’s maintainer) will publicly support Ubuntu 18.04 until April 2023. This means any Python packages they distribute will get bug/security fixes until then.

This shouldn’t have too much weight, however, as desktop users tend to upgrade relatively quickly, and server users are likely to use containers with newer version of Python.

For my libraries, I support end-of-life Python versions plus 3 months

1 Like

No company I have ever worked for has ever upgraded anything “quickly”.

True, but are they also likely to use a new library such as the one described in the original post? I’m suggesting there’s not much overlap

2 Likes

Thanks everyone for those interesting thoughts!
Of course I know that it is a trade-off between work and possible user-base, but I was curious if people have a bit of experience HOW significant this is with Python, what in your own experience, the actual portion of users would be that get excluded if I e.g. decide to require 3.8 instead of still supporting 3.6.
With Java, the number of users insisting on running ancient versions was just immense and my Java stuff all still supports at least back to Java 8.
With Python, my own gut feeling is that people are much more flexible, but I wanted to get the feedback of seasoned developers too rather than only listening to my gut :slight_smile:

It really depends on the library and its users. The ecosystem is diverse.
Generally you could, for example:

  • start with supporting the active Python releases (that would be 3.7+ today)
  • before your “1.0” release, simply drop support for older versions that don’t have features you want/need to use
  • if users/circumstances require it, you can add support for older versions back after the initial release – it’s usually a chore, but not too complicated. (At this point you already know you’ve built something useful so the chore is worth doing, and the relevant versions are newer than when you first started.)
3 Likes