How Is Python 2 Supported in Red Hat Enterprise Linux After 2020?

https://access.redhat.com/solutions/4455511

by rwmj • 7 years ago

61 85 7 years ago

access.redhat.com

While you should move on to python3 at this point I still stand by the whole thing was a giant waste of time. 'Better' unicode support was not worth the mess. Everything else could have been done in python2.

MereInterest• 7 years ago

That's only if you are dealing with an US English userbase who never copy/paste from Microsoft Word. Anything else, and the better unicode support is a godsend. Better have them pop up as type errors during development than as uncaught exceptions whenever a user happens to first put unicode somewhere you don't expect.

dr_zoidberg• 7 years ago

Not just non-US users, but also emojis.

kissgyorgy2• 7 years ago

Your package build probably never broke because you have an accented character in your name...

tick_tock_tick2• 7 years ago

I limit all my non-ascii to comments. The tooling just isn't there to support it.

ASalazarMX3• 7 years ago

I strongly disagree: decoding and recoding strings to-from UTF8 was a monumental waste of time IMO. Never has one language gave so much trouble for simple tasks like reading a database. Python3 just works seamlessly.

loeg6• 7 years ago

Implementation details of u"" could be changed without rototilling the language. Breaking the print statement does not improve unicode support, for example.

jzwinck• 7 years ago

In Python 3 if you have bytes and write them out using the "csv" module, you get something like this:

    b'A',b'B'
    b'1',b'2'

That's not seamless, and I wouldn't say it helps non-English speakers either.

This bug impacts Pandas to_csv as well.

etaioinshrdlu• 7 years ago

I think in hindsight v3 mode could be enabled per file, rather than per program.

That wasn't done, but for reasons that amount to "we don't want to"...

I simply believe the python authors made the wrong choice.

joshuamorton2• 7 years ago

That wasn't done, but for reasons that amount to "we don't want to"...

Well, and giant glaring differences in internals. Python3 and python2 have incompatible bytecodes. Swapping compilers on a per-file basis in a language as dynamic as python isn't possible. Python allows dynamic re-writing of modules and source code. How do you decide which version a module is run with if the module is modified at runtime?

chc• 7 years ago

If you made all the other changes but still called it Python 2, how would that help anything? You're still making the same breaking changes.

And if you're not talking about making all the same changes...then it doesn't sound like everything else could have been done in Python 2.

Havoc6• 7 years ago

I get that enterprise-y stuff is on a more LTS slow schedule, but:

Python 3 was released a DECADE ago - literally. If you've got mission critical stuff running on Python 2 and are panicking now then it's time re-evaluate your life choices.

devnonymous• 7 years ago

Not that I'm against python 3 but please, this dismissive arrogant attitude says more about your experience with python than of people who took their time. Python until at least 3.4 was changing way too fast to be considered as a stable platform to port to. The actual window for migration has been more like 3-5 years. Yes this has been sufficient but not so long that people need to question their life choices for being cautions.

Havoc6• 7 years ago

The actual window for migration has been more like 3-5 years.

Fair - the 2-->3 transition was indeed painful. So 3-5 years actual migration window, with advance notice of "Python3 is coming of another 7-5 years".

Whichever way you look at it - that's a decade advance notice. In a industry that moves exceptionally fast.

If you want to judge me as "dismissive arrogant attitude" for that - so be it.

people need to question their life choices for being cautions.

The life choices phrasing was a poor choice on my part & I apologize for that. Message is unchanged though. To me waiting till support window runs out and then thinking of next step is the exact opposite of "being cautious".

danudey• 7 years ago

In fairness to those developers (of which I was one): Python 3 was released a decade ago, and support for Python 3 in commonly used libraries was released, depending on the library, some time between a decade ago and "not yet".

This has required a lot of engineering work to make libraries function with Python 2 and Python 3 (e.g. pandas, numpy, scipy), to make frameworks work properly on both (e.g. django), and to ensure that the libraries that everything relies on (e.g. mysqldb) get updated, forked, or replaced with rewritten alternatives.

Sure, I as a developer "should have" been writing Python 3 for the last ten years, but for most of those years it would have required rewriting large libraries that I, and other developers, rely on to be productive.

Unfortunately this has meant that instead of starting Python 3 projects over the last ten years, people have been starting Python 2 projects so that they could get their work done in those intervening years.

TylerE3• 7 years ago

Even ignoring the lib issue, there were major performance regressions. Py3 didn’t really become clearly better until at least 3.4.

_bxg1• 7 years ago

This just means there was a network effect amplifying the general reluctance; there may have been a greater impetus on the library developers than the end-users, but the community as a whole still failed to prepare for the future.

alfalfasprout• 7 years ago

Not to mention getting recent version of Python 3 easily usable in enterprise linux distros is a fairly recent trend.

takeda6• 7 years ago

Unfortunately this has meant that instead of starting Python 3 projects over the last ten years, people have been starting Python 2 projects so that they could get their work done in those intervening years.

Joke on them, some extensions you listed didn't even wait until 2020 and already dropped Python 2 support.

flukus• 7 years ago

On the plus side it does serve as a powerful reminder of the costs and technical debt incurred by dependencies and why they should be minimized as much as practical.

We've got some projects based on abandoned libraries that will never be upgraded to python 3, essentially leaving us paralyzed on python 2. These projects were also meant to be deprecated a decade ago so no path forward was ever created, but they cling on to dear life.

rolltiide• 7 years ago

This argument fails when you think of Python2 and Python3 as two distinct languages coincidentally having the same brand name

ASalazarMX3• 7 years ago

Then it doesn't fail. They're nearly identical, it's not like one is Java and the other JavaScript.

loeg6• 7 years ago

Totally. If you've got a legacy Python2 codebase, I'd encourage taking a long hard look at porting to a non-Python family language as an alternative. It's not going to be right for everyone, but it's worth keeping in mind.

PhantomGremlin3• 7 years ago

To the downvoters, you're wrong! Python3 is a distinct language.

This is all you need to know: Python3 broke "Hello, World!"

It doesn't get any more fundamental than that.

djhaskin987• 7 years ago

I use ansible heavily at work which doesn't really support python 3 very well yet. If it were an app I wrote from scratchthe choice would be esi but not all the code I work with and rely on (like ansible) was written recently or is easy to migrate.

nitzmahone• 7 years ago

Not sure what you mean by "doesn't support python 3 very well yet"- Ansible has had support and testing for Python 3 since Ansible 2.2, and has been officially support-with-a-capital-S Supported on Python 3 since Ansible 2.5.

Using Ansible against Python3-only targets used to require manually setting ansible_python_interpreter in the inventory, but since 2.8 also supports automatic interpreter discovery.

Havoc6• 7 years ago

easy to migrate.

Yes I understand that. Legacy code is a pain.

This transition is a decade in the making though. A decade.

Ansible is SEVEN YEARS OLD.

This is not a flaw in the python support / timing model. Decade is practically glacial in software terms. Anyone not keeping pace is on their own imo.

Fun fact...py2 EOL was initially 2015. This is already the bloody extension...

bbayles• 7 years ago

Something to consider: there hasn't been a great way to get Python 3 on RHEL / CentOS until this year. The IUS repo is an option, but it makes distributing a Python 3 package difficult: you have to get EPEL installed, then IUS, then you can finally get your own package in.

I'm happy to be able to drop Python 2 support in my projects, but I've had to hold off on some of them that run on RHEL / CentOS.

orev• 7 years ago

What the situation really highlights is this: don’t make breaking changes to things. Perl 6 had to learn this lesson too.

Linux’s staying power has a lot to do with the policy of “don’t break user-space”

stefan_• 7 years ago

Yeah, and somehow they managed to make versions of Python 3 that are practically unusable due to introducing more syntax later.

Like good luck running Python <3.6 without string interpolation, released in December 2016.

All of this is entirely their fault, particularly with Perl hindsight.

takeda6• 7 years ago

Are you complaining that the language is evolving and provides new features that people want to use?

tyingq• 7 years ago

Decade old code isn't anywhere near the far end of the scale for old, big companies.

baylisscg• 7 years ago

Tellingly they go out of their way to say security fixes are always at their discretion and come from upstream. After explaining that a no feature updates is fine as upstream will be effectively dead. This ain’t Python’s problem Red Hat this has been slated for years

tingletech4• 7 years ago

I've some good luck migrating a couple of things to `pypy`, specifically "Squeaky's portable Linux binaries." [0]

"How long will PyPy support Python2? -- Since RPython is built on top of Python2 and that is extremely unlikely to change, the Python2 version of PyPy will be around “forever”, i.e. as long as PyPy itself is around." [1]

[0] https://github.com/squeaky-pl/portable-pypy#portable-pypy-di...

[1] http://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-su...

geofft• 7 years ago

I mean, it's not like CPython 2 is going to disappear on January 1, either. You can keep using it.

What you lose is a) potential security fixes (you might not care, for your use case) and b) the ability to use other libraries that are Python 3 only, including security updates to libraries whose Python 2 versions are no longer maintained. Using PyPy (or any other Python 2 implementation) definitely doesn't get you b and arguably isn't much improvement on a.

ggm2• 7 years ago

Given what people pay RH for, this makes sense. Given why people like me no longer choose to run RH, this makes perfect sense, as a reason why we don't run RH: The money we pay RH to maintain support for old code can be better invested in converting old code to run on new platforms.

There is a class of client who needs what RH is selling and I am glad they sell it, and that people like my bank can invest in that, because longterm stability of fintech cores for a banking product is very important: People ran applications developed for LEO, in emulation under GEORGE and then subsequently re-emulated on later operating systems because ICL committed to that to meet customer needs. People emulated PDP-11 RSTS inside Vax/VMS for the same reason. People emulate OS360 inside RS6000 based machines..

TL;DR RH supporting Python2 makes perfect sense. If you don't use RH, then this doesn't have to matter to you.

colechristensen2• 7 years ago

Opposite position:

The money you pay supporting security and new/broken features of fast moving upstream targets could be mostly saved with a small portion paid to RH freeing you up to improve your product instead of supporting ever-changing/insecure upstreams.

I have experienced far too many emergencies and worried about relying on far too much insecure old code in environments without RH support.

With RH I could always trust that packages wouldn't disappear overnight, if I built something against RH it would actually still be there in 6m or 6y and that I could really trust that if a security hole was discovered I would be notified and it would be fixed in a way that wouldn't break my stack.

All of that is super valuable compared to moving fast and breaking things myself while dealing with upstreams that move fast and break things too.

In many many circumstances, it is really expensive to stay on the bleeding edge of everything and does not add business value, other than pleasing and attracting magpie programmers.

takeda6• 7 years ago

I worked for a company which paid for RH licenses (they don't do it anymore).

Being conservative is nice, if it comes with stability, but during RHEL6, 6.4 was the first version that was actually stable.

As for breaking your stack, this actually is not that hard. All you have to do is not tie your application to the system.

Since we're talking about Python, if you use RedHat or CentOS, I highly recommend IUS repo[1] in there you can pick which version of Python you want to use (older if you want to ensure stability, newer if you need cutting edge), you also can install multiple versions side by side, and your application is no longer tied to the OS, that means switching underlying OS or upgrading to next major version (for example to RHEL8) is no longer that should affect your application.

[1] https://ius.io

rjsw• 7 years ago

I don't think people emulate OS360 on RS6000 machines, I'm sure they are emulating OS360 on the latest IBM System z mainframes.

ggm2• 7 years ago

yea, you're probably right, I let the rhetoric run a bit rich there.

poppabox• 7 years ago

I was hoping this would be a two word website that just said "It's not" in <h1>

djsumdog• 7 years ago

I really wish these big bulky enterprise and commercial solutions wouldn't prop up this technical debt. Things like ArcGIS an other $10k+ software packages have built in Python2 interpreters. If all of them decide to keep "supporting" py2, a ton of security updates are going to fall through the cracks or become non-uniform across tools.

They've literally had years and years to upgrade their tooling. But considering some of this enterprise crap still has support for VBA (Visual Basic for Applications) we'll probably see Python2 in the wild well into 2030. Makes you wonder how much COBOL is still out there.

crygin• 7 years ago

As an alternative viewpoint, it's bizarre that we can't support these things. Mathematics textbooks from 400 years ago are relatively intelligible, and those from 100 years ago are easily readable. But with computer science, a domain which consists entirely of problems we ourselves invented, we've wedged ourselves into a situation where we are apparently so bad at computer language design (let alone systems engineering/systems architecture) that something surviving for a decade is frankly notable.

gtirloni2• 7 years ago

Programming languages are more like spoken languages than mathematical languages. They evolve fast. Programming languages also are versioned, something that's nonexistent and blurry in spoken languages.

There's no support for Latin in almost any software today and books in Latin can be read by a extremely small minority. Even a English speaker from the 1700s would have trouble with today's English.

zamadatix• 7 years ago

Apples to oranges. I don't think you'd be as surprised if the statement were reworded to "the human brain has more flexibility in parsing to understand intent from text than a computer". The issue is very unlikely to be poor language design as, as you allude, people can parse old code just fine. The thing we're actually bad at is building computers that reason intent from content like we do.

merlincorey• 7 years ago

What are you talking about "surviving for a decade?"

Python 2 was released in 2000 -- part of why Python 3 was called Python 3000, I believe.

tingletech4• 7 years ago

perl code I wrote in 2001-2004 is still running in production today, and I don't think I'll ever need to port it to perl6/roku.

airstrike2• 7 years ago

Makes you wonder how much COBOL is still out there.

The answer is "a lot". Brazil's largest banks still employ "Senior COBOL developers", to name just one example.

gtirloni2• 7 years ago

And rightfully so.

dsimms• 7 years ago

Tangent, sure, why not COBOL? COBOL in the cloud for example with Elastic Cobol:

https://www.heirloomcomputing.com/elasticcobol/

? I mostly just love the name.

fragmede• 7 years ago

Money talks, and RedHat is a business like any other. If customers are willing to pay more than it costs to continue supporting it, why wouldn't they do that?

As to why companies can't move forwards: writing tests sucks. whether it's the scaffolding, or perfect is the enemy of the good, writing tests is harder than it wants to be, if someone hasn't put in the effort to set up the codebase to be ready to accept tests. writing tests are often skipped, especially in older codebases that predate today's culture of testing, and even tests are often wrongly skipped in favor of expediency. Thus refactoring or rewriting old codebases is fraught with fear that it will cause regressions.

potatofarmer452• 7 years ago

For a large deployment of our SaaS software last year, in order to connect to the raw data for their POS, we discovered they were on mainframes running UNIX. Not Linux, Unix. We had to go to a local library, in the old archived basement to find books that guided us on what the hell we were doing.

50 years from now, with new completely different languages being vogue, some poor engineer is going to have to find a book for Python2.

keyle• 7 years ago

Fun story :)

On the plus side, the Python2 will probably not look that different from Python6 :)

potatofarmer452• 7 years ago

I'm sure by then there'll be brainwave controlled programming and the idea of using a keyboard with defined syntaxes will be as silly as punching cards sound to us today haha

beatgammit• 7 years ago

There are plenty of Unix systems out there, such as AIX (and arguably FreeBSD, though it's not certified), that are derived from and could be called UNIX. These systems are still maintained today and generally have the philosophy of "if it ain't broke, don't fix it". And there's definitely some sense in that, and I wish more software projects followed that philosophy.

If you take C code from K&R C, it'll likely still compile with current C compilers. Likewise, I'm sure most C projects from the 80s still compile with current compilers, perhaps with minor changes.

FreeBSD often chooses to improve existing tools instead of replacing them, so it would look more familiar to an old Unix expert than Linux, and there's some solid logic to that.

I think it's a little sad that we have these big disruptive changes like Python 2 -> 3, when Python 2 still works fine and can still be improved without breaking backwards compatibility. Honestly, I think it makes sense to have disruptive changes like that be treated as a new language instead of completely dropping support. I like how the Rest project is approaching it with building compatibility for older versions of the language into current compilers, so you can get the best of backwards compat and modern changes.

How Is Python 2 Supported in Red Hat Enterprise Linux After 2020?

Related Stories