Hacker News Reader

Comment by PaulHoule | Hacker News Reader

The worst thing about Python on Unix is that there is always a system Python you get when you type "python" -- it might have been up to date once, but it will be out of date someday, if only because updating it would break other system dependencies.

Thus when you give a coworker instructions how to run something, they wind up using the wrong Python and will waste hours of their own time and your time wondering why it doesn't work. Or maybe they'll get confused about pip vs pip3 or ...

I've found it's a lot easier to get it right on Windows since there is no system Python for people to get confused about.

Java's xenophobia, its insistence on "100% Pure Java" and the various squabbles that Sun and Oracle have had with other platform companies has actually made Java more reliable across different platforms since people expect to have to manage their Java version and don't have a sense of entitlement that they should just type "python" and have it work.

View on HN

Red Hat ditched the user-accessible default system Python in RHEL 8, but offers ways to have several versions of Python available and ways for sysadmins to configure the target of /usr/bin/python.

Anyway, we're finally near the end of supported environments caring about Python 2, so the difference between pip and pip3 will stop causing most of us problems soon... (Yeah, I know some people will use Python 2 beyond EOL, but at this point that's their task and the task of whomever they pay for assistance, not everyone else's.)

> I know some people will use Python 2 beyond EOL, but at this point that's their task and the task of whomever they pay for assistance, not everyone else's

Virtually every common OS (i.e. Windows, iOS, and Linux) provides Python 2.7 by calling `python`, and Python 3.x by calling `python3` so it's more than "some people" using Python beyond EOL -- it's two languages being used simultaneously.

This is what most languages do when they make a breaking upgrade, e.g. Perl 5.x and Perl 6, or Apache Groovy (which ships two compilers in its Groovy 2 download bundle, i.e. the Groovy 1 compliant one used by Gradle and Jenkins etc, and the later 2012 one with the invoke-dynamic capabilities added. Two weeks ago, the Groovy project managers announced that Groovy 3 would keep on doing this, putting the rewritten parser into the compiler which no-one uses, and keeping the main compiler at Groovy 1 capabilities.)

For all of those common OSes, either Python 2 is no longer installed by default or a plan to do that in the near future has been announced. Many of those are preparing no longer to offer Python 2 at all, though few have already dropped it. I don't think RHEL 9, Debian 11, Ubuntu 20.04 LTS, Windows's new Python stub after the EOL date passes, or 1-2 major versions of macOS in the future will offer it.

Yes, OS vendors will temporarily offer some transition past EOL for the versions they ship. But only temporarily, and only in limited form.

The one thing you can guarantee about the system python is that it's exactly as up to date as the system itself needs it to be. That's why it's there: it's not necessarily for you, unless you happen to be writing something system-level.

Anecdotally I've run into more problems with python than with ruby over this issue, but I think that's just because I'm more familiar with the parts of the ruby ecosystem which let me draw a clear dividing line between system-ruby and my-ruby. My impression (which is probably out of date) is that python tooling tries to bridge the gap, and in my experience that's not worked well, to the extent that I just don't try to use python for anything on OS X.

Reply on news.ycombinator.com