Riccardo Polignieri added the comment: Paul: > it's not possible to tell by inspection the version of a Python interpreter.
True, but it's an implementation detail. Couldn't be solved? Versioned interpreters a la Linux, of course, or maybe how about including some kind of manifest file? Steve: > including versioned executables wouldn't that resolve this issue naturally? Definitely. Paul: > 1. Use the Python executable that's first on PATH: "py" Except, that's currently *almost never* true when I'm inside a venv! (For this to be true, I must give up on versioned shebangs). Now, if only 'py' could *always* look at the PATH *only*, ignoring shebangs - well this would be at least consistent behavior. Now, the absolute worst scenario here is when you have a prompt like "(myenv) $>" screaming to your face that you are inside a venv, and you go "py foo.py" expecting the venv interpreter to execute foo.py, because you are inside a venv, right? But wait!, foo.py was actually written by some Linux hacker, therefore *versioned* shebang, therefore 'py' fetches the wrong (system) Python, therefore no dependencies found, therefore crash. How I'm supposed to solve this? Paul: > The only change I'd consider reasonable here would be a doc change Thanks, it would really help, because I'm afraid I can't make it work for me. Most of all, I would really appreciate some sort of "best practice" suggestion on how to put together 'py', venvs and shebang. At the moment, I'm afraid my provisional policy is as follows: - when outside a venv (almost never) it's ok to 'py'; - when inside a venv (almost always) go 'python' the old way, because 'py' is unreliable here, *unless* you manually check the shebang of your scripts before you execute them. Which practically means - almost never use 'py'. Is this the correct way to go? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28686> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
