
Python 2 will be replaced with Python 3 in the next RHEL major release - alianinfo
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.5_release_notes/chap-red_hat_enterprise_linux-7.5_release_notes-deprecated_functionality
======
dajonker
This is good:

\- Python 2 support officially ends somewhere in 2020

\- most popular packages are now compatible with Python 3

\- Python 3.7 performs about as well as 2.7 with future release expected to be
better

Although it still took way too long, if you consider Python 3.0 was released
about 10 years ago.

~~~
VeejayRampay
The double standard when it comes to Python is mindblowing. No other language
could have gotten away with such ridiculous fragmentation and perf regression
for such a long period of time.

~~~
hyperpallium
I think it's the opposite. When other languages make incompatible changes,
they have serious problems (e.g perl6).

Previous versions of python were back-compatible. Java versions stress back-
compatibility. I don't know if HN can find any counter-examples, of a language
that thrived through an incompatible, code-breaking upgrade.

Python has done everything possible to avoid this fate, by maintaining 2.7.
And I'm not even convinced python has gotten away with yet (e.g. kalite,
offline khan academy, needs 2.7). RHEL may end up reversing this. Give it
another ten years!

Amd the Enterprize is the most back-compatible thing you've ever seen. This
change is going to break lots of code, and they will reverse or lose
customers.

~~~
mratzloff
_I don 't know if HN can find any counter-examples, of a language that thrived
through an incompatible, code-breaking upgrade._

Of course. Swift 3 is one example. Ruby 1.9, as others have pointed out, is
another.

PHP is yet another, and perhaps more relevant because it is close to
contemperaneous. It had its "Python 3 moment" with the migration to PHP 5.
Lots of BC breakages.[0] That transition took about 3-4 years for most.[1]
Most users are now on the current major version, 7, and the remainder on 5 are
mostly using its latest release (EOL is EOY). No one uses 4.

[0]
[https://secure.php.net/manual/en/migration5.php](https://secure.php.net/manual/en/migration5.php)

[1]
[https://web.archive.org/web/20110720002753/http://www.gophp5...](https://web.archive.org/web/20110720002753/http://www.gophp5.org/faq)

~~~
sametmax
Swift 3 is compiled. So you can provide the binaries and be ok.

Ruby 1.9 is a great example of why you should not be too nice: they told
everybody "you have a fews months, deal with it". The community moved. Python
said "poor things, we understand, take those tools and years to do the thing",
and the community cried, and did nothing.

PHP literally failed. They canceled V6 and jumped to V7.

The funniest part ?

None of those languages are even close to Python popularity.

Swift is not even used for most Apple codebase. Python supported even Atari.

Ruby and PHP has almost no use case outside of the web. Python is used by OS,
on the web, in GIS, by data analysts, for CGI, in AI, for sysadmin, to make
GUI, video games...

And Python is much, MUCH older. 1990. 4/5 years older than Ruby/PHP. It has
way more technical debt to pay. Swift ? 2014

Yeah the migration was badly handled from some aspects. But honestly, given
the challenge and track record of the competition, it's not too shabby.

~~~
hartator
Comparing Python and Ruby upgrades is not fair.

Ruby 1.9 was working mostly the same as 1.8 while provising 2-3x speed
improvment, and new exciting features.

Python 3 breaks even the basic Python 2 hello world, everything was notably
slower, and not anything new and exiciting feature-wise apart ubified string
support.

~~~
mratzloff
Yes, Python really botched it.

------
BobBagwill
It's for system use. You should never depend on the vendor-supplied compilers
for anything, because their goals are different from your (the
developer/application-wrangler's) goals. Always develop in a defined,
controlled virtual environment, period. If you want be stylish, there's a
fancy new thing called a container in which you execute your application in
defined, controlled environment. :-)

~~~
ianamartin
This is really by far the most important point in the thread. I understand the
points about embedded use cases and all the other stuff that people bring up
when the flames come out in 2 vs. 3. But this is specifically about RHEL.

If you're using RHEL, the point here is almost entirely moot. You should never
have been depending on system python for anything important anyway. If RHEL
replacing Python 2 with Python 3 breaks any part of your code or your company,
you have already made a huge shit sandwich for yourself.

The fix, however, isn't that bad. Just start using virtual environments. It
will take you a while to unravel hidden dependencies, but it's doable in a
reasonable amount of time.

------
jon_richards
Django also recently dropped python 2. I think it's nice that we're finally
seeing support for Python 2 end. We've been in a frustrating middle ground of
supporting both for too long now.

------
pluc
About goddamn time. Now let's take care of PHP <= 7 and Node <= 8 and us
sysadmins can stop living a foot in a decade ago and a foot in today.

~~~
smt88
> _Node <= 8_

Great! Mostly no problem. The backwards-incompatible changes are few and seem
to rarely be used in the projects I've seen.

> _PHP <= 7_

Totally different story. PHP does upgrade slowly, but many of the backwards-
incompatible changes are almost impossible to detect without 100% code
coverage. A lot of legacy PHP < 7.x code bases are also going to be lacking
perfect coverage.

That said, I think bespoke PHP is less common than people think. The
WordPress/Drupal/whatever installations are major drivers of the usage numbers
for PHP.

~~~
foobarbazetc
We upgraded our bespoke, massive php5 codebase to php7 in a week.

The much bigger upgrade was 4 to 5. We have something like 6 custom C
extensions and that was a huge pain.

php7 is a great language though. Worth the pain.

~~~
smt88
I believe you did that conversion and that it worked for you. I still don't
think it's a slam dunk when you're talking about a stable, production product
that can't have errors. It's almost impossible to do the conversion with
static analysis alone, unless you know something I don't.

------
welder
This is good, but it's sad that #!/usr/bin/env python will no longer work as
the go-to shebang since python won't exist, only python3 will exist by
default.

Geofft[1] has a nifty solution but it's not as cross platform as the old
tride-n-true #!/usr/bin/env python:

#!/bin/sh """"type python3 >/dev/null 2>&1 && exec python3 "$(readlink -f
"$0")" "$@" #"""

""""exec python "$(readlink -f "$0")" "$@" #"""

[1] [https://ldpreload.com/blog/usr-bin-
python-23](https://ldpreload.com/blog/usr-bin-python-23)

------
coliveira
I think this has been the ugliest, most badly managed update for a major
language since Perl6. And this is not completely over, yet. Over the next 5
years I still expect to see people complaining about this Python3 thing. I
hope the designers have learned a lesson.

~~~
pavelbr
Perl6 isn't an update to Perl5. It's a completely unrelated language with a
misleading name.

~~~
eikenberry
You could easily argue the same is true with Python2 and Python3.

~~~
b2gills
With one main difference being that we are perfectly content to let people
continue to use Perl 5. (Most of us anyway)

Another is that Perl 6 brings in many features from other very disparate
languages while making them seem as if they always belonged together. It
doesn't seem like Python 3 brings that many new features.

------
Paul_S
The Internet may switch to 3 but industry will stay on 2.7 for the next decade
and no EoL will change that. There is absolutely nothing that can change that
because there is zero benefit to rewriting a decade's worth of code and no
manager will authorise that.

So don't bin those 2.7 books just yet if you want a job at a big co.

~~~
scolson
... Said the COBOL developers.

To some degree, you may be correct, that there will be companies that refuse
to upgrade for many years. By and large, I think most people will start to
switch:

* Small orgs will begin to see costs of maintaining legacy code skyrocket as it becomes harder and harder to get 2.7 interpreter support for newer kernels. Those that aren't already transitioning now will eventually bite the bullet.

* Medium orgs will probably be the laggards. They have enough funds to pay someone else to make compatible interpreters for them. Your observation about manager authorization very likely applies here so many probably won't bother to upgrade without an internal skunkworks-style initiative.

* Large orgs will upgrade. Their infosec departments will freak out that an old, "potentially insecure" language is being used, regardless of third party vendor support. I see this a fair bit now in the PHP space; where RHEL supports and backports patches for old, insecure versions of PHP, but the infosec people still can't stand it. These days, infosec is getting more and more pull in every huge organization, so it wouldn't surprise me at all to see them start to treat 2.7—or the old, un-updated packages that are locking someone to 2.7—as a possible attack vector and force a change.

All that said, you are right about jobs. If someone knows 2.7 inside and out,
they will start to see higher and higher paying contract gigs over the next
15-20 years. Just like the COBOL programmers saw.

~~~
collinmanderson
...and then there's Mega Large orgs, like Google, who are used to maintaining
their own software.

I am super curious what Google will do. The thing to watch is whether
Chrome/Chromium (and therefore Node.js) can ever be built without using Python
2.7.

~~~
joshuamorton
Mega large orgs have already moved, in some cases. They have the advantage of
being able to throw significant resources into infrastructure to make
switching easy.

~~~
collinmanderson
I'm thinking about Google, Mozilla, Dropbox, etc. They still use a lot of
Python 2.

~~~
rankam
Google created Golang and then created a tool to convert Python2 -> Go.

[https://github.com/google/grumpy](https://github.com/google/grumpy)

~~~
collinmanderson
That grumpy project seems to have stalled in the last 6 months.

I feel like Google hasn't made much progress converting away from Python 2.

Python 2.7 is still required to build Chrome, for example, and I don't think
there are any plans to change that.
[https://bugs.chromium.org/p/chromium/issues/detail?id=61357](https://bugs.chromium.org/p/chromium/issues/detail?id=61357)

And, I believe they use 2.7 whenever they use TensorFlow.

------
ror6ax
Let's hope this will finally change the "compatibility with py3 is a feature"
to "no py3 compatibility - no library" state of things. It's really surprising
how stubborn some teams are.

~~~
pas
What's amazing is that pip3 gladly downloads and tries to install py2 stuff.
Because package/dependency management is a complete afterthought in Python.

And sure, it'll get better, and finally we have lockfiles (Pipenv), and maybe
eventually a proper SAT solver will help resolving dependencies
[https://github.com/pypa/pip/issues/988#issuecomment-36084645...](https://github.com/pypa/pip/issues/988#issuecomment-360846457)
, aaand gradual typing is nice too, and maybe eventually we'll have a proper
async library (python-trio, as asyncio is there, but not low level and/or not
ergonomic enough).

Yet Python is free and open, and amazing, and I haven't contributed much other
than report bugs, so I'm not complaining, just comparing to other ecosystems.

~~~
beagle3
Conda has a silver and has been available for however many years. It also
works well with pip.

Among people complain about python package management, I have never heard an
argument against Conda other than “I don’t like that they recompile base
python”. What’s your reason to discount conda?

~~~
kalefranz
Our python is compiled with the latest versions of gcc (on Linux) and clang
(on macOS). So you're getting gcc 7.2 compiled python on RHEL/CentOS 6. And
all of the security and performance enhancements that come along with it [1].
(Ok we're still on 7.2; we'll update to 7.3 in the next couple months.)

[1] [https://www.anaconda.com/blog/developer-blog/improved-
securi...](https://www.anaconda.com/blog/developer-blog/improved-security-
performance-in-anaconda-distribution-5/)

~~~
kalefranz
P.S. If you're looking for a latest and greatest C/C++ compiler toolchain
that's backed with "production" testing via hundreds of millions of package
installs and works on older versions of linux...

------
lunchladydoris
If this is an issue for you, I would highly recommend that you have a look at
virtual environments via tools like virtualenv and conda. That way you'll be
able to run all the versions you like.

~~~
oblio
I tried this a while ago.

I think Conda allows installing different versions of Python (good) but it
doesn't play well with Pip (bad)? Last I tried it also bundled dependencies in
its own particular way (ugly)? I think it was more geared towards SciPy and
NumPy and other scientific development than towards general purpose
programming.

~~~
kalefranz
> doesn't play well with Pip

The focus of my _current_ right-now dev work is to teach conda to better
understand non-conda-installed python packages so we respect what's already
there even if it's not a conda package.

~~~
oblio
That would be a humongous boon, especially for Windows. I really wanted to use
Conda, but I really, really needed Pip for packages. I don't really remember
what blew up when I tried it, but it wasn't pretty.

Glad to know that soon enough that will be just a memory :)

------
tibbon
I'm a Rubyist. Why are Python users so doubled down on keeping on with Python
2? I can't imagine using Ruby 1.8.x at this point, and even older versions
seem well outside the realm of consideration.

~~~
welder
We're not, nobody uses Python 2 anymore. It's just a shame we have to type
"python3" and "pip3" now even when Python 3 is the default on a distro.

~~~
cup-of-tea
I don't. I use pyenv and it's always just python, even though I have many
different versions on my system.

~~~
welder
Same with virtualenv, but without users of scripts using pyenv or virtualenv
the shebang is broken if it's pointing to #!/usr/bin/env python. Many users of
scripts aren't python developers, so they won't be using pyenv or virtualenv.
Just wish we had a cross-platform way to run python scripts reliably like we
did when /usr/bin/python always existed.

------
w8rbt
I've recently started writing all my scripts in Python 3 as I need to future-
proof some things. And it just works now. No problems. So if you tried Py3
years ago and had issues, try again today.

------
aashu_dwivedi
`brew install python` also installs python3 now

~~~
SjuulJanssen
yes and it took me a while to fix things. I still need to maintain my python2
code

~~~
profunctor
Doesn't OSX come with python2 by default?

~~~
rplnt
It does, what can break is what `python` points to.

~~~
osteele
This is un-broken as of 2018-03-09[1,2,3]. `brew install python` installs
python3, but it only installs a link to this at `/usr/local/bin/python3`, not
`/usr/local/bin/python` (as it did for a while).

In other words, `brew install python` now complies with PEP 394[4].

    
    
      $ brew install python
      …
      ==> Caveats
      Python has been installed as
        /usr/local/bin/python3
    
      Unversioned symlinks `python`, `python-config`, `pip` etc. pointing to
      `python3`, `python3-config`, `pip3` etc., respectively, have been installed into
        /usr/local/opt/python/libexec/bin
      …
      $ ls -l /usr/local/bin/python{,2,3}
      lrwxr-xr-x 1 osteele staff 38 Mar 22 11:23 /usr/local/bin/python -> ../Cellar/python@2/2.7.14_3/bin/python
      lrwxr-xr-x 1 osteele staff 39 Mar 22 11:23 /usr/local/bin/python2 -> ../Cellar/python@2/2.7.14_3/bin/python2
      lrwxr-xr-x 1 osteele staff 34 Mar 31 12:27 /usr/local/bin/python3 -> ../Cellar/python/3.6.5/bin/python3
    

[1]
[https://brew.sh/2018/04/09/homebrew-1.6.0/](https://brew.sh/2018/04/09/homebrew-1.6.0/)

[2] [https://github.com/Homebrew/homebrew-
core/issues/24812](https://github.com/Homebrew/homebrew-core/issues/24812)

[3] [https://discourse.brew.sh/t/python-and-
pep-394/1813](https://discourse.brew.sh/t/python-and-pep-394/1813)

[4]
[https://www.python.org/dev/peps/pep-0394/](https://www.python.org/dev/peps/pep-0394/)

------
exabrial
As someone completely ignorant in everything python... can someone explain why
Python 3 has never replaced Python 2?

~~~
retzkek
For us the primary reason is because not only is Python 2 the default in RHEL
6 and RHEL 7 (and thus downstreams like CentOS and Scientific Linux), they
don't even ship with Python 3 or have it in the base yum repos, so getting it
installed on our thousands of diverse systems is nontrivial.

Furthermore we have a large base of scripts, owned by many people, that use
Python as they would use bash, so changing the default Python on them will be
like linking /bin/bash and /bin/sh to /bin/csh.

~~~
stormking
There's SCL. It's a pain in the ass, especially if you want to ship RPMs, but
it works and is - more or less - official.

------
imikay
Great to hear this, just tried to install Python 3.6 on RHEL yesterday without
luck, ended up downgrading my code to Python 2.7.

~~~
dralley
Did you use SCL?

------
mkj
Anyone know if /usr/bin/python will point to python3?

~~~
ersh
That would be really bad.

The new scripts should just use the right #! string

~~~
moviuro

      #!/usr/bin/env python2
    

There, fixed it.

Much like `#!/usr/bin/env bash` for bash scripts instead of `#!/bin/bash`
(which won't work on many OSes)

[https://github.com/search?q=%23%21%2Fusr%2Fbin%2Fenv+python2...](https://github.com/search?q=%23%21%2Fusr%2Fbin%2Fenv+python2&type=Code)

~~~
saurik
You can't "there fixed it" for the infinite number of projects that exist in
the field that this breaks. "It never worked on FreeBSD" is very different
from "it no longer works on new versions of RHEL".

~~~
Sir_Cmpwn
>You can't "there fixed it" for the infinite number of projects that exist in
the field that this breaks

Of course you can. Python files are plaintext.

    
    
        $ find ./some/module -name "*.py" -exec sed -e 's:#!/usr/bin/python:#!/usr/bin/env python2:g' -i {} ;

------
strkek
I wonder how things will fare for Mercurial, or GYP (used by Node.js).

------
vermaden
Any leaks/leads when Red Hat will announce RHEL 8.0?

~~~
collinmanderson
> We're expecting to hear more about RHEL8 next month. Other current
> expectations are that Btrfs will be completely gutted in favor of the
> company's own Stratis Linux storage tech, the workstation session using
> GNOME on Wayland by default, shipping with the GCC 7 compiler, and possibly
> shipping with the Linux ~4.14 kernel. We're expecting an alpha sometime soon
> and would be perfect if announced at May's Red Hat Summit 2018.

[https://www.phoronix.com/scan.php?page=news_item&px=RHEL-8-N...](https://www.phoronix.com/scan.php?page=news_item&px=RHEL-8-No-
Python-2)

~~~
vermaden
Thank You.

------
qiqitori
> next RHEL major release

This links to the release notes for RHEL 7.5, which was released today, and is
a minor release (in RHEL terms).

~~~
lightdot
"Python 2 has been deprecated Python 2 will be replaced with Python 3 in the
next Red Hat Enterprise Linux (RHEL) major release."

So, deprecated in RHEL 7.5 as a fair warning to everybody and replaced with
Python 3 in RHEL 8.

You'd know this if you had actually read the linked release notes you mention.
;)

~~~
qiqitori
Ah. Still weird to say that "Python 2" is deprecated as of RHEL 7.5 when both
the installation frontend and yum use Python 2.7.5, and Python 3 isn't even on
the installation media.

(Grabbed the ISO and made sure the above assertions are true.)

------
nfoz
They're two different languages. I don't see why python3 "replaces" python2
anymore than say ruby does. IMO they should have separate namespaces and
invocation.

~~~
chungy
They do -- it's trivial to have python2 installed on the same system as
python3. The deal with RHEL is that they will no longer include python2
packages at all.

That isn't really to say that somebody else won't make packages.

~~~
nfoz
Thank you, that's much more clear. So RHEL is deprecating their python2
package i.e. declaring their intent to eventually remove it.

For some reason "replaces X with Y" suggests to me that they swapped one for
the other (e.g. /usr/bin/python) which seems error-prone.

~~~
jononor
There are things included in RHEL which use Python. These will now use Python3
instead of Python2, so from that perspective it has been replaced.

------
ajorg
The real news is that Sendmail is also deprecated.

------
Animats
Several shared-hosting companies don't support Python 3 yet. HostGator's
default Python is still 2.6.

~~~
scardine
Python applications are second class citizens at HostGator and other cheap
hosting services. Most people using Python applications are using VPS,
containers or PaaS because deploying Python applications is a lot harder than
just "drop the files" somewhere like it is with PHP.

------
Avshalom
As a point of reference: Py 2->3 has taken a bit over a decade.

The first electric computer is about 8 decades ago.

------
lerax
The legacy is dying, finally.

------
maxk42
About time. Now fix your vim distro.

------
mhd
But woowee, we might get a Perl from 2015…

