Running Python 2 and Python 3 on the same machine

[Paul Watson]

On Sat, 2008-12-06 at 10:57 +0100, "Martin v. Löwis" wrote:
> > Ok.  I built the source on an openSUSE 11.0 system.  I used 'sudo make
> > altinstll'.  It created an executable /usr/local/bin/python3.0 file.
> > Nothing was touched in /usr/bin.
> 
> Ah, then you missed the fun part. Take a look at the install: target
> in the Makefile.
> 
> > I need to start writing some code with Python 3.  I want to write the
> > code in such a way that it can be easily shared with others with the
> > least difficulty and overhead as possible.  How should I write the code
> > to enable this?  What, if anything, should I assume about another
> > system's configuration?
> 
> I don't quite understand the problem. Sharing code is very easy over
> the internet. You can upload it on PyPI (say), or mail it. So you
> must be asking for something else.
> 
> > As someone suggested before, naming the files as '.py3' is probably a
> > bad idea in the long run.  It also does not really solve the problem.
> > 
> > I could use a shebang.  But, what should it specify?  If I use
> > 'python3.0', then that will soon be quite old.  If I make up a link for
> > python3 -> python3.0, that would work, but then every other system that
> > is to run the code must that link also.  However, I am thinking that
> > this would be the best long term answer.
> 
> Well, this will be rejected. It might be a good medium-term answer, but
> it is a *bad* long-term answer. In the long term, Python 2 will
> disappear, and we are stuck with calling the interpreter python3.
> 
> > If I write scripts for Python 3, another developer writes scripts for
> > Python 2, and a common customer wants to install both of our packages
> > onto a single machine, then what is the best plan for everyone to make
> > that happen with as little difficulty as possible?
> 
> My recommendation is to use distutils, for a long-term answer. People
> will run "python3.0 setup.py install", and distutils' install_scripts
> will replace the shebang line with the actual path to Python 3.0.
> This has not only the advantage of continuing to work for 3.1; it has
> also the advantage that scripts installed into a private location will
> be run by the correct interpreter (rather than relying on the
> interpreter being in /usr/bin, or on PATH).
> 
> For "quick" sharing, the shebang line "#!/usr/bin/env python3.0" will
> be enough. When Python 3.1 gets released, you may find yourself writing
> scripts that run only on Python 3.x for x>=1 (i.e. won't run on 3.0,
> because you use a new feature in 3.1). In that case, presence of a
> python3 executable won't help, either.
> 
> Regards,
> Martin

Yes!  Finally we are getting somewhere.  I can see how this can work for
distributed packages.  I still have two questions.

I do not mean to take your individual time for this.  If there is
documentation I should read, please suggest it.

First, let's say that the package has been installed using distutils and
the shebang line is set to '#!/usr/local/bin/python3.0'.  Now, Python
3.1 is released with a number of speed performance improvements and
several security fixes.  The existing application is hardcoded to use
Python3.0 directly.  Does distutils include any mechanism to update this
setting so that the package will use a different interpreter?

Must the application be installed again in order to update the shebang
lines?

Second, we frequently have a number of standalone utilities written in
Python.  When the task requires excessive effort to write in a shell
script, Python is a great answer.

What is your recommendation for the shebang line on one-off, single .py
file utility scripts?