Isn't that an Arch bug? Last I heard, there was consensus in the upstream Python community that /usr/bin/python should not be Python 3, which makes sense because Python 3 is deliberately incompatible with Python 2. Of course, that viewpoint might have changed.
But still, even if upstream disagrees, I think it is the responsibility of the packagers not to break ABI compatibility in this way (just as they wouldn't ship OpenSSL 1.0 as libopenssl0.9.8.so). I'm pretty sure every script that uses Python 3 uses python3 in the shebang.
You're talking about PEP 394[1]. It suggests that "python" point to either "python2" or "python3", depending on what ships with the distro by default or on the distro's stated goals. Arch tries to be as cutting edge as possible, even putting out new kernels within weeks after their release. It makes sense for Arch to begin pushing the boundaries here.
There was a discussion on the arch-dev-public mailing list[2] recently that you might be interested in.
In any case, I think it's clearly beneficial for every new Python application to make their version requirements explicit in the hashbang.
Cool, thanks for the pointers! I'm a little disappointed that Debian doesn't seem to be shipping the python2 symlink, which means that I can't switch to using that in my own code.
But still, even if upstream disagrees, I think it is the responsibility of the packagers not to break ABI compatibility in this way (just as they wouldn't ship OpenSSL 1.0 as libopenssl0.9.8.so). I'm pretty sure every script that uses Python 3 uses python3 in the shebang.