An Easier Way to Keep Old Python Code Healthy and Secure

Python has its pros and cons, but it’s nonetheless used extensively. For example, Python is frequently used in data crunching tasks even when there are more appropriate languages to choose from.

Why? Well, Python is relatively easy to learn. Someone with a science background can pick up Python much more quickly than, say, C. However, Python’s inherent approachability also creates a couple of problems.

Whenever Python is updated, it means a big refactoring workload, which often gets dealt with poorly – or not at all. That leads to poor performance and security vulnerabilities. But maybe there is a better way: a tool to keep your Python tasks running smoothly and securely day in, day out. Let’s take a look.

****It’s slow, but it does the job****

Python isn’t the fastest language around, but despite its comparative disadvantages, you’ll often see it used for intensive data crunching operations. Think machine learning, computer vision, or even pure math in high-performance computing (HPC) systems.

So, despite its performance reputation, very tough workloads are commonly handled with Python code, simply because it’s so practical to use. If you have a science or math background you can relatively easily learn Python and produce your own code that will do the job.

But, as is often the case, something that’s accessible can also create a lot of risks. Inexperienced programmers writing Python code can struggle with tasks that more experienced programmers take for granted.

****Refactoring is a hassle… and a risk****

Like all programming languages, Python goes through frequent updates. The shift from Python 2.7 to Python 3.0, for example, brought a whole bunch of features and improvements. It also means that anything written for Python 2.7 needs to be “refactored” for Python 3.0 due to changes in how Python works.

Refactoring refers to the way programmers adjust a code base to respond to environmental changes, such as a change in the language version, or just to improve existing code in some form. Without refactoring, a shift from Python 2.7 to Python 3.0 often means the code for Python 2.7 just doesn’t work that well anymore, or even at all.

And here’s the problem: the users who wrote the original Python code might not have the expertise to refactor. After all, they’re often scientists – and not experienced programmers. When inexperienced programmers attempt to adjust code there’s a real risk that performance will degrade and that bugs will creep in – sometimes only visible when an edge case appears. Small bugs become a major concern when Python code is used for critical, 24/7 purposes such as scientific analysis.

Refactoring can also lead to unexpected performance degradation. Even if it’s just a 5% performance hit, a poorly executed code update can quickly create much bigger bills on expensive pay-for-use HPC platforms.

****Sticking to old Python? That’s an even bigger risk****

If you think about the hard work and risks involved in adjusting code, it’s no surprise that users often choose to just stick to older versions of Python. Running existing code on an outdated version of Python avoids quite a lot of challenges because you don’t need to refactor: you’re keeping your code just the way it was.

Commonly, software vendors will do exactly that – only updating their software to match a new Python version when they release a new version of the software product. If you’ve purchased a specific version – running on, say, Python 2.7, you’re stuck and you need to continue running Python 2.7 no matter what.

It doesn’t sound like a big problem, but relying on outdated, unsupported building blocks for your computing is a DevSecOps nightmare. New vulnerabilities will appear, and the needed patches just won’t come. Relying on old versions of programming languages, therefore, introduces huge risks into your computing environment.

****There’s little choice in it – or is there?****

The responsible thing to do is to update the Python version when needed and to edit the code running on it but there just isn’t a painless way to do it. Realistically, due to a lack of resources, refactoring often doesn’t get done, with potentially costly consequences.

There’s a major need for a better approach, and here’s what’s interesting. The situation we just described around Python versions is frequently seen in the world of computing. For example, it’s common for organizations to run versions of the Linux operating system that are no longer covered by official vendor support, taking the risk that security vulnerabilities won’t be patched just to make sure critical applications don’t break.

That is a problem for language updates as well as other pieces of IT infrastructure too. But, in recent years, advanced patching solutions allow companies to extend the usual support lifecycle for multiple components, from whole operating systems, to specific critical shared libraries. Here at TuxCare, we’ve developed several solutions that extend the safe, secure operation of older software beyond the vendor’s end of life.

****Running older Python apps safely and securely****

What if the same could be done for language versions? Well, you can now look forward to running your older Python code, on an old version of Python – but without the risks that it entails. No deprecated language constructs – and no vulnerabilities either.

In other words, extended lifecycle support for language versions – such as Python – is becoming a reality. You’ll soon be able to keep your Python code safe and secure without the need to rewrite a single line of code, simply by getting extended lifecycle support for Python – which gives you the same security protection as a full version upgrade.

Set to roll out at accessible prices, TuxCare’s Python extended lifecycle support will help your organization deal with the difficult questions around older Python workloads. Keep an eye out for our announcement – which is coming soon.

Found this article interesting? Follow THN on Facebook, Twitter  and LinkedIn to read more exclusive content we post.