Any reason not to use /usr/bin/env python2/python3 explicitly? [closed]

倾然丶 夕夏残阳落幕 提交于 2019-12-11 02:50:18

问题


I often see this at the top of .py files:

#!/usr/bin/env python

With the unknown state of the OS defaults, I wonder why it's not:

#!/usr/bin/env python2
#!/usr/bin/env python3

If most OSs provide this versioned symlink, wouldn't that be better?

I found PEP 394 while looking around, which states that for the time being, developers should assume python -> python2 -> python2.x. It also states that one can assume that the versioned equivalents, python3 and python2, exist. So what's the harm in not leaving it to chance and providing that extra character?

If one doesn't have python2 installed because the OS ships by default with python -> python3 (like Arch linux), I'd much prefer this issue when running a script or program:

/usr/bin/env: ‘python2’: No such file or directory

Alternatively, this error is much worse, particularly for a new user (python exists, it's just the wrong version):

File "<stdin>", line 1
  print 'Hello world'
                    ^
SyntaxError: Missing parentheses in call to 'print'

That said, I find the latter far more common. At least now I know some typical compatibility errors well enough to think to myself "Oh, right. It's the python symlink."

Two questions ask how to specify/verify the desired version:

  • This 2010 question suggests treating python as meaning python2 and python3 as required to explicitly call out python3.

  • This 2013 question: maybe implies that python3 shouldn't be used because not all distros ship with it?

Is there an obvious reason I (or python programmers) shouldn't use a versioned env call if most OSs provide it? To use just python is seeming to cater to a minority who don't have the versioned command while causing confusion to the vast majority who do.

Maybe the answer is to use versioned commands (I'm getting that from PEP 394) but enough time hasn't elapsed to see them appear. To date I've never seen a versioned env call... then again, if it works I never look. If it breaks, it's always a version-less python line so my mental counts are probably skewed!


Some github stats on searches; I was curious on usage:

  • #!/usr/bin/env python2: ~210k python file code hits
  • #!/usr/bin/env python3: ~460k
  • #!/usr/bin/env python: ~6 million

This could mean that most code is old enough that if the recommendations of the questions above was the prevailing wisdom, folks just haven't updated their files?


I looked at these popular OSs and found them all to use versioned commands:

  • ubuntu: python-minimal and python3-minimal
  • arch: python and python2
  • fedora: python2 and python3
  • debian: same names/state as ubuntu
  • various sources suggest that OS X uses versioned commands
  • windows: I think there's evidence that windows has versioned commands available

回答1:


When you write the script, you may induce various dependencies on a particular version of Python. Use a dict comprehension? You need at least Python 2.7. Using the async keyword? You need at least Python 3.5.

When you use #!/usr/bin/env python, you aren't saying anything about which version of Python is required to execute your script; you are just saying "Use whatever version of Python is found in your path first." Fundamentally, the developer is the wrong person to specify the shebang.

Instead, the user should be setting the shebang to the path of the correct version of Python on their system.

The distutils package strikes a good compromise here. You, the developer, just put #!python in your script. When you install the script via python setup.py install, the installer replaces #!python with whatever path is correct on the target machine.



来源:https://stackoverflow.com/questions/45046409/any-reason-not-to-use-usr-bin-env-python2-python3-explicitly

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!