Hacker News Reader

Comment by mrosett | Hacker News Reader

The code I've written recently relies heavily on async and data classes, both of which are recent additions. I can't imagine choosing Python 2 at this point.

View on HN

My team is moving across from Bash to Python for non-trivial scripting. I hate it, but we're adopting Python 2.x. Our old servers are on SLES 11 which has Python 2.6 and even our new boxes have RHEL 7 which has Python 2.7 only by default. Getting the base system packages updated across all our systems and environments would be monumentally painful, so we're really stuck. It's not that Python 2.x is painful to use or anything, it's still a great language but being stuck using it seems pointless.

I'm really upset at the distro vendors, they should have upgraded their base system Python scripts to 3.x years ago and just included 2.7 for legacy support. RHEL 7.0 came out in 2014 for goodness sake.

Let's check the package "python" in Ubuntu...

14.04 (2014): Python 2

16.04 (2016): Python 2

18.04 (this is obvious but... less than 12 months ago!): you guessed it, Python 2 (!!!)

So, still in 2018 and until 2020 (when I guess the next LTS release of Ubuntu is scheduled) all instructions over the internet telling you to run "python" or "pip install" will run Python 2 if copied into your Ubuntu terminal.

I already said this in a previous discussion about Python 2 vs. 3: what a lost opportunity.

You should assume that python means “2” and python3 what it says in the name. The bigger problem is that invoking “python3” and having a script developed for “python3” still doesn’t guarantee that the script will work, there were incompatible changes during python3 history.

Arch Linux has the packages the other way around: the 'python' package is Python 3 while there is a python2 package and binary.

I guess Ubuntu has it that way to stop the breaking changes however

You should expect python to be Python 2 because that's the official recommendation, for compatibility: https://www.python.org/dev/peps/pep-0394/

New code has no problem explicitly requesting python3, old code needs changing to request Python 2, but if you touch it anyways it's of course safer to make that change.

In case anyone thinks Arch is being crazy here and ignored the PEP (and doesn't read the PEP), note the change here was written in 2011 and approved in 2012 based on Arch's experience moving to python 3 by default in 2010.

#!/usr/bin/env python3

there were incompatible changes during python2 history as well. RHEL shipped Python 2.4 forever, and now ships 2.7. There are many breaking changes between those two versions.

This has always been true. New syntax or libraries were added in almost every major Python version.

If python2 was python2.2, it wouldn't support `with`. It's just that python2 has been Python 2.7 for a decade, so it's been relatively stable.

Please enable additional repos (EPEL, IUS) providing sane Python versions. Python 2.6 isn't even supported by pip anymore. RHEL appeals to "enterprise" people for claiming to be able to run the same software for ten years without adaptations. It's a seductive trap imho.

why would I add 3rd party repos to install a modern python when I can just run my sysadmin python scripts under the system python without worrying about it? python2 is a perfectly good python for 99% of the things need to do

But definitely not Python 2.6!

For cases like this, I compile the scripts with nuitka. It's heavy, but worth every additional MB since it avoids massive technical dept. It also makes deployment as easy as scp.

> Our old servers are on SLES 11 which has Python 2.6 and even our new boxes have RHEL 7 which has Python 2.7 only by default.

Not to sound condescending... But why does this single default matter that much?

I'm sure you install lot of things onto these machines which isn't there by default, right?

Why is installing Python 3 on top of all those other non-default packages such a problem?

I prefer to install as few 3rd party packages as possible. In RHEL7 until recently Python 3 was only available via 3rd party repos, until EPEL added it. So now it's not that big of a deal to install python3, but before that why would I go about adding ius or something to get a modern python when there's a perfectly fine Python 2.7 built into the system for running sysadmin jobs?

> perfectly fine Python 2.7

Not sure how you see a system being deprecated in 2020 as perfectly fine.

Same here. Dataclasses and type annotations are fantastic, not to mention f-strings.

This is all fine for personal/proprietary purposes, but open source can't be that cutting edge. While type annotations are probably fine (3.5), f-strings (3.6) or dataclasses (3.7) won't make it to mainstream OSS anytime soon. But they are great features nonetheless.

> open source can't be that cutting edge.

what?

I mean, RHEL 8 is shipping with Python 3.6 and Python 2.7 available. There is no standard /usr/bin/python without making the symlink manually, and the system uses its own internal python for dependent tooling, so it doesn’t conflict with user installed versions.

And, based on my experience, general open source is usually much more cutting edge than the larger distros, that’s the whole point.

Reply on news.ycombinator.com