Running Python 2 and Python 3 on the same machine

"Martin v. Löwis" martin at
Sat Dec 6 10:57:29 CET 2008

> 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 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.


More information about the Python-list mailing list