PEP 394: Allow for more flexibility in handling /usr/bin/python by hroncok · Pull Request #989 · python/peps (original) (raw)

I don't think always using "/usr/bin/python3" is generically good advice for new code, since I think requiring the python3 spelling is ultimately a transient thing - I expect most distros to follow Fedora's approach, and make python refer to python3 by default once they drop their full Python 2 stacks, and I expect we'll eventually change the Windows launcher to at least fall back to Python 3 for unqualified shebang lines, and potentially even prefer it over Python 2.7 once the latter goes end-of-life.

So I think it's entirely reasonable for publishers to continue to use "/usr/bin/env python" as their default approach, and tell anyone with a system where that doesn't work to either:

  1. Use an appropriately configured virtual environment; or
  2. Set up a shell alias or user level symlink so it works for their personal account; or
  3. Convince the system administrators to make it work by default across the entire machine; or
  4. Edit the shebang line to be correct for their system before running the script (if editing a shebang line is problematic, folks should be using installers, not downloading scripts directly)

While specifying /usr/bin/env python3 instead is an entirely reasonable alternative, that offers some potential benefits and is hence well worth mentioning, that's a far cry from telling all current publishers "Your script shebang lines are now wrong, and you should change them" (or, even more irritatingly, encouraging folks to go around submitting PRs to open source projects along the lines of "PEP 394 told me that /usr/bin/env python is wrong, so now I am going around and submitting 'Change python to python3 in shebang lines' PRs to every open source Python project I can find").