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?