Running Python 2 and Python 3 on the same machine

[Paul Watson]

The migration strategy detailed in PEP 3000 using 2to3 is quite nice.
However, I am looking for suggestions for migrating to 3 while I still
have code that requires 2.

Since the source code is incompatible, I was expecting the Python
executable to have a new name such as 'python3' or for the default
source code filename to change to '.py3' or something.

Yes, I have searched some on the web and the newsgroup, so please don't
beat me up if this is well known. Thanks.

 

[Martin v. Löwis]

Since the source code is incompatible, I was expecting the Python

executable to have a new name such as 'python3'

It does: the executable is called python3.0.

or for the default
source code filename to change to '.py3' or something.

Such a proposal would be rejected. In a few years from now, Python 2
will be gone, and we would be stuck with an ugly file extension
(similar to how \windows\system is now an empty directory, and
\windows\system32 actually contains the 64-bit binaries on x64)-

Regards,
Martin

 

[Terry Reedy]

It does: the executable is called python3.0.

Why do you say that? As I reported on the py3 list when requesting a
new name -- in particular, python3, the new python is installed on WinXP
as python.exe and pythonw.exe!!! The includes the new 3.0 release.

 

[Paul Watson]

It does: the executable is called python3.0.


Such a proposal would be rejected. In a few years from now, Python 2
will be gone, and we would be stuck with an ugly file extension
(similar to how \windows\system is now an empty directory, and
\windows\system32 actually contains the 64-bit binaries on x64)-

Regards,
Martin

I have to agree with Terry; installing the released python-3.0.msi
results in an executable named 'python.exe' in the filesystem. I have
not built it yet, but I assume the *NIX package results in a 'python'
executable file.

For a machine that runs existing Python 2.x applications, what should be
in the PATH variable?

For *NIX machines, will 'python' be placed into /usr/bin? If so, then
the Python scripts that start out with a shebang like the following will
have difficulty.

#!/usr/bin/python
#!/usr/bin/env python

Has there been any guidance issued?

 

[Martin v. Löwis]

Why do you say that?

Because it is - on Unix. I assumed that was the platform that the OP
cared about.

Regards,
Martin

 

[Martin v. Löwis]

For *NIX machines, will 'python' be placed into /usr/bin?

Not by default, no. Just try it and see for yourself.

Regards,
Martin

 

[Paul Watson]

Not by default, no. Just try it and see for yourself.

Regards,
Martin

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.

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?

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.

#!/usr/bin/env python3

My existing /usr/bin directory has three entires for python.

python -> python2.5
python2 -> python2.5
python2.5

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?

When we find out the answer to this, we can go back and talk about
Windows platforms.

 

[Martin v. Löwis]

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

 

[Paul Watson]

Ah, then you missed the fun part. Take a look at the install: target
in the Makefile.


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.


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.


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?