[Python-Dev] #!/usr/bin/env python --> python3 where applicable

[Kevin Teague]

On Apr 18, 2009, at 1:08 PM, Mitchell L Model wrote:

> Some library files, such as pdb.py, begin with
> 	#!/usr/bin/env python
> In various discussions regarding some issues I submitted I was told  
> that the decision had been made to call Python 3.x release  
> executables python3. (One of the conflicts I ran into when I made  
> 'python' a link to python3.1 was that some tools used in making the  
> HTML documentation haven't been upgraded to run with 3.)
>
> Shouldn't all library files that begin with the above line be  
> changed so that they read 'python3' instead of python? Perhaps I  
> should have just filed this as an issue, but I'm not confident of  
> the state of the plan to move to python3 as the official executable  
> name.

Hrmm ...

On installing from source, one either gets:

./bin/python3.0

Or is using 'make fullinstall':

./bin/python

So the default and the tutorial (http://docs.python.org/3.0/tutorial/interpreter.html 
) refer to 'python3.0'. But I've done all my Python installs with  
'make fullinstall' and then just manage my environment such that  
'python' points to a 2.x or 3.x release depending upon what the source  
code I'm working on requires. If using something such as the Mac OS X  
Installer you'll get both a 'python' and 'python3.0'.

Are there some Python installers that provide './bin/python3'?

But if there sometimes just 'python', 'python3.0' or 'python3' then  
it's not possible for the shebang to work with both all known install  
methods ...

One could argue that executable files part of the python standard  
library should have their interpreter hard-coded to the python  
interpreter to which they are installed with, e.g.:

#!/Users/kteague/shared/python-3.0.1/bin/python

Of course, this would remove the ability for a Python installation to  
be re-located ... if you wanted to move the install, you'd need to re- 
install it in order to maintain the proper shebangs. But it would mean  
that these scripts would also use the correct interpreter regardless  
of a user's current environemnt.

Or, if the standard library was packaged such that all of it's scripts  
were advertised as console_scripts in the entry_points, it'd be easier  
for different install approaches to decide how to write out the  
shebang or to instead provide wrapper scripts for accessing those  
entry points (since it might be nice to have a ./bin/pdb). But that's  
a bit pie-in-the-sky since entry_points isn't even yet a part of the  
Distutils Metadata.