Convince people not to use an “end-of-life” Python 3.X version

Question

Context

At my company, we have a major Python package which is written in Python 2. We are now planning to migrate it to Python 3 (we don't care about keeping it Python 2 compatible).

I am a junior developer and my coworkers are senior people, who don't have a strong computer science background.

Issue

During the planning process, we needed to answer the question of the minimal Python version we want to support. The chosen answer was Python 3.4, for some internal reasons. However, Python 3.4 will reach end-of-life in 5 months (so probably even before this package is ported to Python 3)

I don't like the idea of supporting a Python version which is not supported by the Python organisation anymore but I can't find concrete arguments against it, others than "it just doesn't feel right".

Arguments I thought about are:

• we'll have less Python versions to support: if we start on 3.5, we have to support one less version, 3.6 two less versions, etc.
• we can use new language features

About the first one, others said that we will test only the minimum supported version on our CI and that developers of this package will use the latest as our local development environment. It's unsafe in terms of testing, but I have to admit differences between Python 3.X versions are not breaking so much stuff, especially given what this package does.

About the second argument, people are not really aware of the new features from Python 3.5 and higher and they tend to say: "we do it today in Python 2, so I don't see the point of having new features". Also, in the context of this package, there are no new features I can really advertise as being super nice (like async stuff for instance).

Questions

• What are the consequences of using a Python 3.X version which has reached end-of-life? I can find resources about Python 2 vs Python 3, but can't really find anything specific to old Python 3.X releases vs new ones.
• What are strategies to raise awareness about keeping software up to date? How to change people's mindset so that they don't find it normal to use outdated tools?

Answer 1

The software development lifecycle is more than development – it also involves maintenance and decommissioning or replacement of the software. So asking “what about in X years” is generally a sensible question.

The big reason why you want to use a supported Python versions is security, especially for network-connected software. Using a recent Python version gives you a longer support period without having to do more development work. For the same reason, you would (hopefully) not design a new system for Windows XP or Android 4 or Ubuntu 16.04. For Python, the EOL date only applies to the official CPython development, which matters if you compile yourself or download official binaries. If you use a Python that is delivered with the operating system, the operating system vendor might provide different support periods.

Note that you might be legally required to follow state of the art security practices such as running supported software versions, for example if your software processes personal data and is subject to the GDPR (see Art. 32).

From a development standpoint, supporting multiple Python versions is easy (especially when you are Python 3.4+ only), and upgrading to new versions is trivial beyond some tiny fixes (e.g. Python 3.7 turned async into a new keyword).

• The biggest pull-factor to new versions are crucial language features that make development more pleasant (e.g. async, type annotations, f-strings, ordered dicts, inline assignment) and standard library improvements.
• A push-factor to drop older versions is the wider library ecosystem: many libraries do not like wasting effort on supporting EOL'ed Python versions. If you don't upgrade, you would have to fork those libraries and backport any bugfixes yourself, which is a lot of effort.

So while you can use an older Python version just fine, there's no good reason to do so – except when you have external constraints. For example a requirement like: “the software has to run on this server, and this server only has Python 3.4 installed. We cannot install another Python version.” Sometimes removing those constraints is easier (i.e. lobbying for an OS update, or deploying via containers), but in the context of non-async code and Python 3.4, just writing compatible Python code is usually the path of least resistance.