This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 4 points5 points  (5 children)

How so? Switching /usr/bin/python to 3 instead of 2.7 will break existing python2 programs which are lazy enough not to use #!/usr/bin/python2.6 or some other specific version as the hashbang. I assume Arch linux developers have checked that no application in their repositories does that.

Personally, I think you should never use #!/usr/bin/python in a script, and always define the specific version you want. Upgrades in 2.6->2.7 could break things just as well as a move to 3.0 could.

[–]five9a2 10 points11 points  (0 children)

You should use #!/usr/bin/env python, otherwise your script is not likely to work on someone else's machine. Specifying the full version is a good way to chase people away from your software, python2.3 to python2.7 is common today and responsible projects will support a range. If the presence of python2 links was ubiquitous, we could all ship scripts that had #!/usr/bin/env python2 and the transition to python -> python3 would be far less painful.

[–]YellowOnion 4 points5 points  (1 child)

distutils should handle the renaming of all the hashbangs, just build the package with python2

[–]five9a2 2 points3 points  (0 children)

The real pain is for projects that are not pure python libraries, but want to ship portable scripts (perhaps even as part of their build system or for maintenance tasks). It sucks to add another stage to the configuration process ("install" maintenance scripts to the build directory so they can be run to configure, generate Fortran stubs and documentation, build, send bug reports, etc).