Running Python 2 and Python 3 on the same machine
"Martin v. Löwis"
martin at v.loewis.de
Sat Dec 6 04:57:29 EST 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 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
More information about the Python-list
mailing list