How acceptable is it to use end-of-life (EOL) versions of Python in educational or production environments? Status of Python versions explains what EOL is, while Development cycle page provides a brief definition for the term as well, but nothing more.
Is there any citable source that EOL versions of Python are not advisable to use, especially since they pose a security threat?
Would something like this suit your needs?
I’m curious, is this to convince people who do not understand the implications from the lack of security updates?
In terms of educational uses I think it’s less about security and more about giving people an up-to-date education.
Many aspects of Python have been consistent for many years, but it feels like a disservice to teach people to use deprecated methods or old syntax, while not introducing them to new syntax they will encounter in their programming career.
Keeping educational materials up-to-date can be a lot of work, but EOL versions are many years old. A course doesn’t need to cover the latest-and-greatest in 3.13[1] but it shouldn’t be stuck on 3.7 or something.
that would probably be just as confusing, as a lot of projects aren’t using it yet ↩︎
I am trying to convince an institute that Python 2 or 3.6 are not the best things that they can teach students. Moreover, sometimes I try to convince companies or people to switch to newer Python versions. I would enjoy if I can just refer to a piece of documentation that explains why usage of EOL Python versions leads to security, usability and other issues. I might even write it myself, just point the appropriate place.
@hugovk, would it be acceptable to document it somewhere in the devguide or docs? It might seem obvious, yet it’s often missed.
This is not specific to Python; it’s continuously emphasized in every security standard.
For example:
https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-137a
Implement asset and patch management processes to keep software up to date. Identify and mitigate unsupported, end-of-life, and unpatched software and firmware by performing vulnerability scanning and patching activities.
I think the blog post is overly broad. Stable existing software without security issues and written and debugged to run on old Python can continue just fine as long as maintainers are available. This includes educational software that is not teaching a particular version of Python. Anything with security vulnerabilities should be upgraded. In Fall 2024, I think courses teaching Python should be teaching at least 3.12, released a year ago. Similarly into the future.
In this case, numerous CVEs (2.7, 3.6) might make avoiding security issues with older Python harder, especially when outdated dependencies are added to the mix. I would side with CISA that running older versions of Python is not advisable. Additionally, older versions might have lower performance, requirement to install older versions of Python to run some software decreases software’s usability and maintainability (some newer libraries might be unavailable, you might have to need older versions of software to run it in the first place), not to mention it’s directly uncompliant to the security advisory.
For education, especially, using EOL versions has the drawback of severely limiting access to Python’s wider package ecosystem.
If you’re a student learning Python, chances are very good that you want to use it for something, like data science (numpy, etc.), machine learning (pytorch, etc.), web development (django, etc.). These packages often do not support old Python versions (sometimes they drop support even before the official EOL date).
Using 3.8 or older in teaching is a disservice to students.
That is a typical user experience when working with unsupported software:
Python 3.6 wasn’t even supported on ARM64 for Windows/macOS. You’d be forcing students to run under emulation which should work in theory although there are plenty of extra pitfalls and bugs.
My intent is to prevent usage of EOL versions anywhere. However, it takes more than opinion to convince someone, so I was looking for resources to support my point of view and I also proposed creating documentation that people can reference to when they share the same goal.
I tried to be as neutral as possible, so I asked for opinions and links to documentation first.
My clarity might be better, since I see that many people assumed that I support usage of EOL.