Hacker News new | ask | show | jobs
by rlpb 3422 days ago
My Python 2 scripts on Github start with "#!/usr/bin/python", as do many others. All of these broke for you as an Arch user.

Because Arch did what they did, Python now recommends that Python 2 scripts start "#!/usr/bin/python2" (or the env equivalent).

> Are we to hold back for the lowest common denominator? Do we need every distro to join together and agree to a switchover date?

It's not just other distros; it's the rest of the world, including all of the scripts that people run but distros don't necessarily ship.

The right way to migrate would be to ship and use both /usr/bin/python2 and /usr/bin/python3. Leave /usr/bin/python as a symlink to python2 for a while. Eventually, drop the symlink, but do not replace it with python3. Allow users to opt-in to a compat symlink if they wish. Let stuff catch up. When the expectation that "python" is python2 has faded, then introduce a symlink from python to python3 by default, letting users opt-in earlier if they wish.

> There was official guidance from Python on the switchover, this wasn't some maverick decision.

No, there wasn't, and yes, it was some maverick decision. It was done without consultation with upstream.

(I am a non-Arch distribution developer)

2 comments

This just feels like culture clash to me - the whole change to Python 3 was about accepting the cost of breaking changes to avoid dragging around useless cruft and bad decisions forever.

The idea that we should then never use `python` to mean `python3` is just so backwards. Sure, in your corporate environment where backwards compatability is suepr important, do that.

In Arch, people have a distro that moves fast and breaks things, and we are fine with that. I'll accept the cost of occasionally having to change a shebang line (although as I have almost never had to go outside the AUR - someone else in the Arch community has almost always dealt with this for me).

> No, there wasn't, and yes, it was some maverick decision. It was done without consultation with upstream.

Fair enough, I got my timelines mixed up - but to be fair, it was then ratified as the correct way to do things because the upstream project agreed with the core idea.

> The right way to migrate would be to ship and use both /usr/bin/python2 and /usr/bin/python3. Leave /usr/bin/python as a symlink to python2 for a while. Eventually, drop the symlink, but do not replace it with python3. Allow users to opt-in to a compat symlink if they wish. Let stuff catch up. When the expectation that "python" is python2 has faded, then introduce a symlink from python to python3 by default, letting users opt-in earlier if they wish.

I don't really see why I should have to do this manually? If you don't want that behaviour, use another distro. This just feels like you feel like you should have some say in how other people set up their systems.

If you really hate it so much, don't support Arch - that'd be fair. Trying to shame the distro for doing it ignores the fact it's the core idea of the distro to do stuff like that, that's the point.

> The idea that we should then never use `python` to mean `python3` is just so backwards.

I did not present any such idea. I presented a sane migration path to where `python` means `python3`.

> ...it was then ratified as the correct way to do things because the upstream project agreed with the core idea.

No. It was because the upstream project had their hand forced and are pragmatic about these things.

> I don't really see why I should have to do this manually?

In my proposal for a sane migration path to the ideal? You wouldn't have to do it manually. The distribution would do it. As a user you'd be able to override it to speed up the migration for yourself if you chose; that's all.

I chose to run a bleeding edge distro to be on the bleeding edge. Requiring me to make the changes to be on the bleeding edge manually makes no sense.

Expecting that is as weird as expecting super stable LTS releases to run the latest-and-greatest of everything.

> Requiring me to make the changes to be on the bleeding edge manually makes no sense.

Which part of "You wouldn't have to do it manually" do you not understand?

Which part of "I want it now, not in the future" do you not understand?

> In my proposal for a sane migration path to the ideal? You wouldn't have to do it manually. The distribution would do it. As a user you'd be able to override it to speed up the migration for yourself if you chose; that's all.

I want to speed up the migration for everything - that's why I run Arch. That 'override' is a manual step I don't want to have to do.

> My Python 2 scripts on Github start with "#!/usr/bin/python", as do many others. All of these broke for you as an Arch user.

So you made certain assumptions. Have you made your scripts use python2, which is safer anyway, everything would've been fine, don't blame Arch for your incorrect assumptions.

No. Before Arch made their change, that /usr/bin/python is Python 2 was the only possible assumption that could be made. No distribution shipped /usr/bin/python2 at that time. There was no need, because /usr/bin/python was always Python 2.

It was only because of what Arch unilaterally did that forced the community to start providing a /usr/bin/python2. Before that, /usr/bin/python2 did not commonly exist at all.

> It was only because of what Arch unilaterally did

Arch is a bleeding-edge, latest software kind of distribution. They did not made the decision 'unilaterally'. They made the decision to ship the latest software for their own distribution, as they always do. It may have proven that a lot of software is extremely poor/inflexible, (i.e. rests on weak assumptions), but I am glad Arch moved forward as that showed their resolve to move technology forward even in the face of a lot of pressure from outside groups.

I just think that instead of blaming Arch, try to make your scripts more robust, i.e. loop on all 'python*' binaries in /usr/bin and use the first one whose --version gives you '2.x' instead of relying on /usr/bin/python being python 2 when the latest version is 3 and Arch is known to ship latest software.

> They made the decision to ship the latest software for their own distribution, as they always do.

As did all the other distributions. Shipping Python 3 is not the issue here. Breaking compatibility with all existing Python 2 scripts is what they did. The two are not mutually exclusive.

> I just think that instead of blaming Arch, try to make your scripts more robust, i.e. loop on all 'python<glob>' binaries in /usr/bin...

You want me to do that in a shebang line? No. That'd be crazy.

> ...when the latest version is 3 and Arch is known to ship latest software.

See https://en.wikipedia.org/wiki/Application_binary_interface. What Arch did was break the ABI of what /usr/bin/python means, breaking all scripts that relied on that ABI. Shipping the latest software is orthogonal to this. The rest of the world ships the latest software too, but without breaking ABI.

The rest of the world explicitly doesn't ship the latest software, check the kernel version in the latest version of ubuntu vs arch, same for GNOME etc. Ubuntu did not even had python3 installed for a long time by default, you had to apt-get it

The ABI was never documented and at best a convention-enforced one.

> Ubuntu did not even had python3 installed for a long time by default, you had to apt-get it

I call your straw man. As I've already repeatedly said, the issue is about breaking ABI, not about what software distributions shipped, nor what they had installed by default. Making /usr/bin/python point to Python 3 has nothing to do with what distributions shipped, nor what they had installed by default. The issues are completely orthogonal. Stop trying to pretend otherwise.

> The ABI was never documented and at best a convention-enforced one.

Upstream shipped build systems that put Python 2 in /usr/bin/python, and Python 3 in /usr/bin/python3. That's about as good a definition of ABI as one gets in the free software world. Arch deliberately patched the ABI. You can try to argue that their decision to do so was correct, even though I disagree. You cannot argue that they didn't know they were changing an ABI when they patched the ABI.