> Why duplicate functionality already available in the shell though?
Well, the only reason that functionality is available in the shell is that python is capable of processing python scripts. The shell isn't. So this question doesn't make sense to me.
#!/usr/bin/env python3 heading an executable script.py means "when I execute this file, I really mean 'run the command /usr/bin/env python3 script.py", and that means "run the command 'python3 script.py'.
And running scripts by invoking python yourself is absolutely standard. Consider "python setup.py install" or, for django, "python manage.py shell".
The functionality is available in the shell to let you execute scripts without having to know or care what language or version something is written in. That's taken care of by the script author who puts the appropriate shebang in there instead.
I'm not suggesting that the shell would execute Python scripts, I'm suggesting that the shell can be used to dispatch the script to the correct Python version. Just like all the other scripting languages. You seem familiar with the concept, so I don't get what's confusing about it.
I agree that 'python' should read the shebang when available, at the moment PEP 394 says it should mean 'python2' but is subject to change in the future, but it's easy to solve the problem yourself. Either invoke scripts directly with the ./script.py syntax, or make a script that reads the shebang and uses the right version and then symlink that as 'python' instead.
Well, the only reason that functionality is available in the shell is that python is capable of processing python scripts. The shell isn't. So this question doesn't make sense to me.
#!/usr/bin/env python3 heading an executable script.py means "when I execute this file, I really mean 'run the command /usr/bin/env python3 script.py", and that means "run the command 'python3 script.py'.
And running scripts by invoking python yourself is absolutely standard. Consider "python setup.py install" or, for django, "python manage.py shell".