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.