Hacker News Reader

Comment by Dunedan | Hacker News Reader

HEADER

Python 3 as default

DESCRIPTION

Just to quote from the packaging manual:

> Debian currently supports two Python stacks, one for Python 3 and one for Python 2. The long term goal for Debian is to reduce this to one stack, dropping the Python 2 stack at some time.

The first step for that would be of course Python 3 as default Python version and I'd like to see that for buster, as Python 3 nowadays offers way more features than Python 2 and should be the choice for new Python projects.

View on HN

Upstream Python specifically recommends against installing Python 3 as /usr/bin/python; see PEP 394 at https://www.python.org/dev/peps/pep-0394/ . Beyond that, many of Debian's python-using packages are already migrating over, and I'd expect the rest to likely migrate in buster.

To quote from the abstract of PEP394:

> * for the time being, all distributions should ensure that python refers to the same target as python2 .

> * however, end users should be aware that python refers to python3 on at least Arch Linux (that change is what prompted the creation of this PEP), so python should be used in the shebang line only for scripts that are source compatible with both Python 2 and 3.

> * in preparation for an eventual change in the default version of Python, Python 2 only scripts should either be updated to be source compatible with Python 3 or else to use python2 in the shebang line.

That's just a recognition of the existence of that particular quirk of Arch, and that people may need to cope with that. It's remarkably painful, in practice, to deal with the one special distribution that makes "#!/usr/bin/python" do the wrong thing. And unfortunately, some other distributions don't have a "python2" or "python3" binary, making it painful to write portable scripts; you can't write "#!/usr/bin/python2" or "#!/usr/bin/python3" and expect it to work on every distribution out there.

As mentioned, Debian is working on migrating scripts to support Python 3, and doing so using /usr/bin/python3 , which already appears in the shebang of a large number of Debian's Python programs.

Arch has had python2 and python3 binaries for a long time. /usr/bin/python2 has been there since at least 2010 https://git.archlinux.org/svntogit/packages.git/commit/trunk...

Yes but not the other distributions. Which makes it difficult to write portable scripts.

But ultimately isn't the first choice for most Python projects to date. So many scripts have python paths expecting python 2 hardcoded and pretty much everything that wants python3 calls python3. I'm firmly against this for compatibility reasons, it breaks too much.

Calling python3 for a python 3 binary is ok

I don't see how older python 2 programs can be supported without updating the hashbang line in a Py3 default system (which is most of the time trivial) - you could also have a dedicated virtualenv for them as well which would work - and which would (looks like to) be an equivalent amount of work as changing the hashbang lines

Switching to default Py3 is a breaking change and that's fine

> Switching to default Py3 is a breaking change

Not only breaking, but also completely unnecessary

Python 2.7 being EOL at a future date means switching to Python 3 is needed

Perhaps then a better solution is just to remove the `/usr/bin/python` symlink, and make scripts be explicit in their dependency list.

It would be a small change (that could be automated) in packages, and removes any confusion about what /usr/bin/python means.

Sounds like a dangerous precedent to start removing symlinks or otherwise not linking to the latest version? Is that just a foil to stand in for proper updates to other scripts and such.

Shouldn't instead scripts be updated either to be compatible with latest python or to specify the version they demand?

even if Guido denounces 2 completely, I'm ready to bet some $$ that 2 will be alive and well long after that date

The "lintian" packaging static-analysis tool has been issuing an info-level message about new packages that introduce Python 2.x packages. I've just upgraded this to a "warning" level, so we should at least curb the influx of additional Python 2 packages unless strictly necessary — I suspect most of them are simply included now out of habit.

Reply on news.ycombinator.com