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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
