
How Is Python 2 Supported in Red Hat Enterprise Linux After 2020? - rwmj
https://access.redhat.com/solutions/4455511
======
poppabox
I was hoping this would be a two word website that just said "It's not" in
<h1>

------
djsumdog
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
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.

~~~
gtirloni
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.

------
potatofarmer45
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
Fun story :)

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

~~~
potatofarmer45
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

------
Havoc
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.

~~~
danudey
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.

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

~~~
melling
That was 5 years ago.

I don’t do a lot of Python, and have been exclusively using v3, but I thought
you could make your Python 2 somewhat compatible with v3 by using libraries,
etc.

How close can you come to a Python code base that runs in v2 and v3?

~~~
joshuamorton
> How close can you come to a Python code base that runs in v2 and v3?

Using the `six` module, this is (nearly) trivial for 99% of code. If you're
doing certain weird things, its more difficult but possible. (I say this
having done py2-3 conversion or dual support for lots of vanilla code, as well
as a significant amount of weird code: c/c++ extensions and code that uses
advanced features like code object introspection and dynamic
imports/rewriting/etc).

~~~
tingletech
I have some libraries I maintain with `six` -- I find it like writing in a
whole new dialect (neither 2 nor 3).

I moved to futurize for some libraries -- its like writing python 3 that will
run on python 2.

I am looking forward to dropping python 2 support on libraries I maintain.

------
tick_tock_tick
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.

~~~
ASalazarMX
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.

~~~
jzwinck
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.

~~~
agoodthrowaway
Sorry but I don’t agree this is a bug. You need to decode your bytes to
properly write a string. Otherwise you get the unexpected result you are
showing because it has no way of knowing how your bytes are encoded.

------
ggm
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.

~~~
colechristensen
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.

~~~
takeda
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](https://ius.io)

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

My point is the opposite, I want to tie my application to a reliable system so
I don't have to deal with something else (pip, gem, npm, mvn, etc.) because
those things break, I can't rely on them being available, I can't rely on
packages always being there, I can't rely on the security of what is out
there.

I can rely on the system python and associated packages, I can trust that
security issues will be patched, and I can trust that compatibility will be
maintained. Doing that I would be stuck with an aged and aging upstream
perhaps blocking adoption of new technologies, but it buys me stability and
peace of mind. There are tradeoffs, for sure.

------
tingletech
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...](https://github.com/squeaky-pl/portable-pypy#portable-pypy-distribution-
for-linux)

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

~~~
geofft
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.

------
baylisscg
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

