An easier way to keep old Python code healthy and secure

Python has its pros and cons, but it is widely used nonetheless. For example, Python is frequently used in data processing tasks, even when there are more suitable languages ​​to choose from.

Why? Well, Python is relatively easy to learn. Someone with a scientific background can understand Python much faster than, say, C. However, Python’s inherent accessibility also creates some problems.

Every time Python is updated, it means a significant refactoring workload, which is often poorly handled, if at all. This leads to poor performance and security vulnerabilities. But maybe there’s a better way: a tool to keep your Python tasks running smoothly and securely day in and day out. We’ll take a look.

It’s slow, but it does the job

Python is not the fastest language, but despite its comparative disadvantages, you will often see it used for intensive data processing operations. Think machine learning, computer vision, or even pure math in high-performance computing (HPC) systems.

So despite its reputation for performance, really tough workloads are usually handled with Python code, simply because it’s so convenient 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 is accessible can also create a lot of risk. Inexperienced programmers writing Python code may struggle with tasks that more experienced programmers take for granted.

Refactoring is a chore… and a risk

Like all programming languages, Python undergoes frequent updates. Moving from Python 2.7 to Python 3.0, for example, brought a whole bunch of features and improvements. This also means that anything written for Python 2.7 must be “refactored” for Python 3.0 due to changes in how Python works.

Refactoring refers to how programmers adjust a code base to respond to environmental changes, such as a language version change, or simply to improve existing code in some form. Without refactoring, a move from Python 2.7 to Python 3.0 often means that Python 2.7 code no longer works as well, if at all.

And here’s the thing: the users who wrote the original Python code might not have the expertise to refactor. After all, they are often scientists – not experienced programmers. When inexperienced programmers attempt to tweak code, there is a real risk that performance will degrade and bugs will creep in – sometimes only visible when a borderline 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 cause unexpected performance degradation. Even if it’s only a 5% performance hit, a poorly executed code update can quickly create much larger bills on expensive, paid-for HPC platforms.

Sticking with old Python? It’s an even greater risk

If you think about the hard work and risk of adjusting code, it’s no surprise that users often choose to stick with older versions of Python. Running existing code on an outdated version of Python avoids many challenges because you don’t need to refactor: you keep your code as it was.

Typically software vendors do just that – only update their software to a new version of Python when they release a new version of the software product. If you bought a specific version – running on, say, Python 2.7, you’re locked in and have to keep running Python 2.7 no matter what.

It doesn’t seem like a big deal, but relying on outdated and unsupported building blocks for your IT is a DevSecOps nightmare. New vulnerabilities will appear and the necessary fixes just won’t come. Relying on older versions of programming languages ​​therefore introduces huge risks into your IT environment.

There are few choices – or are there?

The responsible thing to do is to update the Python version when needed and change the code that runs in it, but there’s just no painless way to do that. Realistically, due to a lack of resources, refactoring is often not done, with potentially costly consequences.

There is a great need for a better approach, and here is what is interesting. The situation we just described around Python releases is common in the computing world. For example, it is common for organizations to run versions of the Linux operating system that are no longer covered by official vendor support, risking security vulnerabilities not being patched. just to make sure critical apps don’t break.

This is a problem for language updates as well as other pieces of IT infrastructure. But, in recent years, advanced patching solutions allow companies to extend the typical support lifecycle for multiple components, from entire operating systems to specific critical shared libraries. At TuxCare, we have developed several solutions that extend the safe and secure operation of legacy software beyond vendor end-of-life.

Running Old Python Applications Safely

What if the same could be done for language versions? Well, now you can expect to run your old Python code, on an older version of Python, but without the risks that comes with it. No outdated language constructs – and no vulnerabilities either.

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

Ready to deploy at affordable prices, TuxCare’s Python Extended Lifecycle Support will help your organization deal with difficult questions regarding legacy Python workloads. Keep an eye out for our announcement – coming soon.

About Jon Moses

Check Also

AlmaLinux 8.7 is now available – Latest trends in digital transformation | Cloud News

Distribution continues to closely track RHEL releases, includes enhanced Defense Information Systems Agency (DISA) technical …