running python 2 vs 3

[notbob]

Dumb noob questions:

I've installed python 3.3 on my Slack box, which by default comes with
python 2.7. I know how to fire up the different IDLE environments,
but how do I differentiate between the scripts? IOW, up till now,
I've used .py on all my 2.7 files. How do I know not to run a .py in
python3 or visa versa? Or do I? What's the excepted convention for
differentiating between the two?

nb

 

[Marko Rauhamaa]

I've installed python 3.3 on my Slack box, which by default comes with
python 2.7. I know how to fire up the different IDLE environments, but
how do I differentiate between the scripts? IOW, up till now, I've
used .py on all my 2.7 files. How do I know not to run a .py in
python3 or visa versa? Or do I? What's the excepted convention for
differentiating between the two?

That's a bit of a sore spot.

On a linux box, the initial line of the script indicates the
interpreter:

#!/usr/bin/env python2

for Python 2.x

#!/usr/bin/env python3

for Python 3.x.

All tutorials will tell you to start it with

#!/usr/bin/env python

which will start python2 on all (?) existing linux distros, but is
expected to start python3 within the next decade.


Marko

 

[notbob]

That's a bit of a sore spot.

On a linux box, the initial line of the script indicates the
interpreter:

#!/usr/bin/env python2

for Python 2.x

#!/usr/bin/env python3

for Python 3.x.

All tutorials will tell you to start it with

#!/usr/bin/env python

which will start python2 on all (?) existing linux distros, but is
expected to start python3 within the next decade.

Ahhh! ....now a shabang I understand. So, I guess the only way, short
of looking at the actual file, is to include the version in the
filename. Can I safely assume I can run all 2.7 files w/o a shebang
(which I have not, so far, and was wondering how I got away with that)
and only include a py3 shebang in the py3 files, yes/no?

nb

 

[Mark H Harris]

I've installed python 3.3 on my Slack box, which by default comes with
python 2.7. I know how to fire up the different IDLE environments,
but how do I differentiate between the scripts?

hi notbob, the two (or more) IDLE environments run very nicely
side-by-side. If you access your scripts from the same directory (I do
not) there really is no problem. The reason is that the .pyc files
created for python2.x are only used by python2. The .pyc files for
python3.x are kept (by a naming convention) in __pycache__ , so there
really is no problem. Having said that, the only problem is that your
script for python3 might not run in python2 (for various reasons) but
the problem is not that the scripts are contained in the same folder.

I keep my python2 scripts in one folder ~/Documents/Python2/ and my
python3 scripts in another one ~/Documents/Python3/

I add the two folders in the python paths browser (using site-packages)
so that when I start IDLE for python2 it pulls its scripts from
~/Documents/Python2/ and when I start IDLE for python3 it pulls its
scripts from ~/Documents/Python3/

There are *many* ways to organize this. Often I have to maintain two
scripts (packages) one for each version. Although, I try to make my
scripts run in both environments. Often I have IDLE(2) ane IDLE(3)
running and testing at the same time on the same box. This works very well.

marcus

 

[Zachary Ware]

Ahhh! ....now a shabang I understand. So, I guess the only way, short
of looking at the actual file, is to include the version in the
filename. Can I safely assume I can run all 2.7 files w/o a shebang
(which I have not, so far, and was wondering how I got away with that)
and only include a py3 shebang in the py3 files, yes/no?

If I understand your question: you're probably better off putting a
shebang line in all of the files that you intend to run directly. Use
"/usr/bin/env python2" for your Python 2 scripts, "/usr/bin/env
python3" for your Python 3 scripts, and "/usr/bin/env python" for
scripts that can run under either interpreter. You can also be more
version-specific if you need to; use "python2.7", "python3.3", etc. as
necessary. That way, you can invoke the script directly and the right
interpreter will run it. If you're specifying the interpreter in your
command (by calling "python <scriptname>.py", etc), the shebang won't
mean anything anyway.

 

[notbob]

If you're specifying the interpreter in your command (by calling
"python <scriptname>.py", etc), the shebang won't mean anything
anyway.

DOH!

I was following you, fine, until that last sentence. Then how should
I invoke the scripts? ....as your example is exactly how I've been
doing it with 2.7, as per Learn Python the Hard Way. Simply
../<scriptname>.py from the appropriate directory (assuming I keep both
vers in separate dirs)?

nb

 

[notbob]

not) there really is no problem. The reason is that the .pyc files
created for python2.x are only used by python2.

Lordy, what hath I wrought!?

What the heck is a .pyc file and how are they created? Actually, I
can see it's a compiled binary, but I where did it come from?

I went back to my ~/python/ dir and noticed one .pyc file out of 15
..py files I created from following Learning Python the Hard Way. No
one said anything about creating a binary. I know I discovered how to
create/edit python scripts from IDLE. Is that it? I've been using
gedit and emacs up till now. Seems the file with the .pyc file is the
one I edited in IDLE. Is that why LPtHW eschews IDLE for gedit?

Why do I feel like I've really stepped in it?

nb

 

[Chris Angelico]

Lordy, what hath I wrought!?

What the heck is a .pyc file and how are they created? Actually, I
can see it's a compiled binary, but I where did it come from?

I went back to my ~/python/ dir and noticed one .pyc file out of 15
.py files I created from following Learning Python the Hard Way. No
one said anything about creating a binary. I know I discovered how to
create/edit python scripts from IDLE. Is that it? I've been using
gedit and emacs up till now. Seems the file with the .pyc file is the
one I edited in IDLE. Is that why LPtHW eschews IDLE for gedit?

Why do I feel like I've really stepped in it?

You should be able to completely ignore .pyc files, most of the time.
The only thing to remember is that you should delete them any time you
delete the corresponding .py files. They're a cached version that
Python will use to speed up imports, nothing more.

Nowadays they'll be pushed away into a separate directory, which makes
them easier for you to ignore. This is a good thing.

ChrisA

 

[Chris Angelico]

DOH!

I was following you, fine, until that last sentence. Then how should
I invoke the scripts? ....as your example is exactly how I've been
doing it with 2.7, as per Learn Python the Hard Way. Simply
./<scriptname>.py from the appropriate directory (assuming I keep both
vers in separate dirs)?

That's a fine way to do it. Zachary is mentioning an alternative, and
showing that the shebang doesn't hurt (it's a comment to Python), so
go ahead and put the shebang in all your scripts.

ChrisA

 

[Mark H Harris]

What the heck is a .pyc file and how are they created? Actually, I
can see it's a compiled binary, but I where did it come from?

The world according to me: python is an interpreter (vs compiler) which
converts your source code into tokens and then into a bytecode.

The process takes time. So, the solution is to place the tokenized stuff
into a .pyc file so that the process does not have to be repeated
unless, of course, the source has changed since the last .pyc file create.

It used to be that the .pyc files went into the same dir as the source
(that's how it works for python2) but now with python3 they go into a
directory in your source tree called __pycache__, and they are named
based on python version (a way better scheme for sure).

If you wanted to you could run your python scripts from the .pyc file
alone. In other words, you may import as long as the .pyc file exists
and the source does not need to be there. Some folks use this (not
recommended) trick to hide or obfuscate their source from their users).

marcus

 

[Gary Herron]

DOH!

I was following you, fine, until that last sentence. Then how should
I invoke the scripts? ....as your example is exactly how I've been
doing it with 2.7, as per Learn Python the Hard Way. Simply
./<scriptname>.py from the appropriate directory (assuming I keep both
vers in separate dirs)?

nb

If you mark your script as executable (chmod ...) and include the
shebang line, and place it in a directory included in your search path
(mine is ~/bin), then you run it as you run any installed program:
Just type it's name followed by any command line args. I usually
remove the .py portion of the name as I copy it into my bin directory so
it really does look like any other installed program.

If you need to be in a specific directory when you run it, then perhaps
you should consider a bit of a rewrite to remove this constraint.

Gary Herron

 

[Marko Rauhamaa]

Nowadays they'll be pushed away into a separate directory, which makes
them easier for you to ignore. This is a good thing.

Still, I don't think Python should go and soil my directories without an
explicit permission.


Marko

 

[Marko Rauhamaa]

If you wanted to you could run your python scripts from the .pyc file
alone. In other words, you may import as long as the .pyc file exists
and the source does not need to be there. Some folks use this (not
recommended) trick to hide or obfuscate their source from their
users).

I've seen it done, but at least in those Python 2 days the pyc format
changed between minor releases of Python, so Python itself had to be
shipped with the pyc files.


Marko

 

[Ned Batchelder]

I've seen it done, but at least in those Python 2 days the pyc format
changed between minor releases of Python, so Python itself had to be
shipped with the pyc files.

Python3 still makes no guarantees about the compatibility of bytecode
(and therefore .pyc files) across versions of Python, so if you want to
run from pure .pyc files, you have to be sure to use the same version of
Python that produced the files.

--Ned.

 

[Mark Lawrence]

That's a bit of a sore spot.

On a linux box, the initial line of the script indicates the
interpreter:

#!/usr/bin/env python2

for Python 2.x

#!/usr/bin/env python3

for Python 3.x.

All tutorials will tell you to start it with

#!/usr/bin/env python

which will start python2 on all (?) existing linux distros, but is
expected to start python3 within the next decade.


Marko

The above is also true on windows via the 'Python launcher for windows'
see http://legacy.python.org/dev/peps/pep-0397/

 

[Eric Jacoboni]

Le 20/03/2014 16:21, Marko Rauhamaa a écrit :

All tutorials will tell you to start it with

#!/usr/bin/env python

which will start python2 on all (?) existing linux distros, but is
expected to start python3 within the next decade.

With Arch-Linux, python is python3...

 

[John Gordon]

I was following you, fine, until that last sentence. Then how should
I invoke the scripts? ....as your example is exactly how I've been
doing it with 2.7, as per Learn Python the Hard Way. Simply
./<scriptname>.py from the appropriate directory (assuming I keep both
vers in separate dirs)?

There are two ways (at least!) to run a python script:

1. Execute the python interpreter manually, supplying the python script name
as an arugment, like so:

python myscript.py
python2 otherscript.py
python3 yetanotherscript.py

This lets you choose on-the-fly which version of python is being used to
interpret the script.

2. Execute the python script directly by just typing its name, like so:

myscript.py
./otherscript.py
/other/directory/yetanotherscript.py

Depending on your operating system, this may require:
a. Permissions on the script file be set to allow execution;
b. A 'shebang' entry as the first line in the file which specifies the
program that shall be executed;

 

[Mark H Harris]

I've seen it done, but at least in those Python 2 days the pyc format
changed between minor releases of Python, so Python itself had to be
shipped with the pyc files.

hi Marko, yeah, I have not done this; being that the concept is contrary
to my principles and sensibilities these days. So,

1) no intellectual property
2) no software idea patents
3) no obfuscated code
4) ship the source, or don't ship anything/

In my view coding (and all other aspects of computer science including
software engineering) is a liberal art; it should be open, free (libre),
and available to everyone. People learn best by doing, and the do best
by reading what others have done before them.

marcus

 

[Alan Meyer]

On a linux box, the initial line of the script indicates the
interpreter:

#!/usr/bin/env python2

for Python 2.x

#!/usr/bin/env python3

for Python 3.x.

All tutorials will tell you to start it with

#!/usr/bin/env python

which will start python2 on all (?) existing linux distros, but is
expected to start python3 within the next decade.


Marko

I presume it would still be a good idea to test both python interpreters
against any script that you didn't knowingly write with a feature that
will only work in one of the two python versions.

If it works fine in both - and many will, then use:

#!/usr/bin/env python

Only use the "python2" or "python3" versions if you really have a reason
to do so.

Yes? No?

Alan

 

[Marko Rauhamaa]

I presume it would still be a good idea to test both python
interpreters against any script that you didn't knowingly write with a
feature that will only work in one of the two python versions.

If it works fine in both - and many will, then use:

#!/usr/bin/env python

Only use the "python2" or "python3" versions if you really have a
reason to do so.

Yes? No?

No. Even if you managed to do that, it would mean getting the worst of
both worlds. The language dialects are too far apart. When you start
your Python project, you decide between Python 2 and Python 3 and go all
in.


Marko