running python 2 vs 3

[Terry Reedy]

What the heck is a .pyc file and how are they created?

..pyc contained compiled bytecode. They are created when, and only when,
you import a module. Imported library files are often big and stable,
so their compiled forms get cached. Top-level scripts are typically
short and often volotile. They may be as short as "from start import
run; run()" in order to have as much as possible stored in compiled form.

This has nothing to do with Idle.

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.

That must be the only one you imported.

 

[Terry Reedy]

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;

c. An association between '.py' and some version of python.

3. Use the python launcher py.exe with version selection.
py -2 myscript.py
py -3 myscript.py

As far as I know, this is only for Windows at present.

 

[Marko Rauhamaa]

Weeping Chryst on the cross!!. No wonder the latest O'Reilly book,
Learning Python, 5th ed, is 1600 pgs. I coulda swore someone sed
python is easy.

It's not that bad. There are two principal dialects: python2 and
python3. Take the oldest python version you have to support and write
your code for that version.

Python documentation carefully explains what language and library
facilities are available in whichever version.


Marko

 

[notbob]

That must be the only one you imported.

So it is. Thank you.

nb

 

[Marko Rauhamaa]

I'm not sure how to take this comment. I feel like you are mocking my
choice. I wanted to make coverage.py available to as broad an audience
as possible, something that I think is worthwhile. Yes, there was an
engineering cost, but the tradeoff was worth it.

I can't judge if your particular choice was the right one. My only point
is that python2 and python3 are so far apart as to be regarded as
independent languages.


Marko

 

[Steven D'Aprano]

To avoid nausea, I write sys.stdout.write() in all Python3 code.

Now that's funny.


I-know-I-shouldn't-respond-to-obvious-trolling-but-I-can't-help-myself-ly
yrs,

 

[Mark Lawrence]

I can't judge if your particular choice was the right one. My only point
is that python2 and python3 are so far apart as to be regarded as
independent languages.

And I still say this is complete nonsense.

 

[Chris Angelico]

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.

They're not that far apart. It's not difficult to write code that runs
happily on both. However, it does mean you can't take advantage of
Python 3 features, so it's probably better to write for one or the
other, unless you specifically want wide distribution. For your own
projects, just put whichever you need.

ChrisA

 

[Chris Angelico]

I can't judge if your particular choice was the right one. My only point
is that python2 and python3 are so far apart as to be regarded as
independent languages.

They're definitely not independent languages. The biggest change is
str/unicode->bytes/str, and you can get part of that in Python 2.6/2.7
with "from __future__ import unicode_literals". You may still run into
problems with some functions that expect str and won't take unicode
(or vice versa), but it's easy to make code that runs across both
versions that way. Then toss in "from __future__ import
print_function" and happily use the expanded features of print, or go
for the lowest common denominator:

print("some single string")

which works happily in all versions of Python.

I've written code that runs on 2.6+/3.2+. (Or maybe it's 3.1+;
whichever version Debian Squeeze ships with.) It's pretty easy. It's
certainly a lot easier than writing code that runs as either Pike or
C++, for instance. THOSE are independent languages. (And yes, I've
written that sort of code. Had a #define block up the top to handle
some naming differences, and then restricted myself to a *really*
narrow set of common operations. Was a neat way to prove correctness,
though.)

ChrisA

 

[Steven D'Aprano]

Weeping Chryst on the cross!!. No wonder the latest O'Reilly book,
Learning Python, 5th ed, is 1600 pgs. I coulda swore someone sed python
is easy.

This has nothing to do with Python. It has to do with the way executables
(applications) are mapped to file names on Unix and Unix-like systems.
And that in turn is not terribly different from the way that it works on
Windows as well.

When you type "python" at the command prompt, your system locates an
executable named "python", then runs it. If you wanted to be annoying,
you could alias or link the python name to a completely different
language. Or use a different name altogether:

steve@orac:~$ alias snake=python
steve@orac:~$ snake
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.


This has nothing to do with Python, it's the way Linux works.

 

[Steven D'Aprano]

Yes, and they have been told many times that this was foolish and wrong,
but it persists, much to our pain.

How bizarre. I've been looking forward with great pleasure to Fedora
moving to Python 3 as the standard system Python, expecting that this
move from one of the big distros will start a chain reaction of others
doing the same thing. Perhaps Arch-Linux is guilty of being prematurely
Python 3, a little like those people hauled up to explain themselves to
the House Unamerican Activities Committee to explain why they were a
"premature anti-fascist".

I have no idea what "our pain" you are referring to, or who "our" refers
to. In the three or five years or so since Arch-Linux moved to Python 3
by default, I don't recall ever seeing even a single email from somebody
confused by Arch-Linux's move, not here, or on the tutor mailing list, or
on Python-Dev or Python-Ideas. Nor have I seen any signs of difficulty or
confusion on Python-related blogs, or StackOverflow.

That's not to say that there has been absolutely none at all. The
Internet is a big place, and I daresay I've missed something. But given
how small the Arch-Linux share of the Linux space is, I would be
astonished if their move caused more than a tiny little ripple. Perhaps a
paper-cut worth of pain. I expect that there have been far more angry
words written over this issue than the actual consequences of the move
itself. Unless you're in the unfortunate situation of having to migrate
and maintain scripts across a network of mixed Linux distros including
some that are Arch-Linux, it's difficult to see exactly what pain they
could be causing even in principle.

 

[Steven D'Aprano]

This is fine advice for applications, but tools, libraries, and
frameworks may want to support more than one version at the same time.

+1

Actually, even applications may want to support multiple versions. If I
have a Python script that does something, I might not want to tie it to
one specific version. In principle there's not much difference between
"this will run under Python 2.6 and 2.7" and "this will run under Python
2.7 and 3.3". In practice, it's a little trickier to cross the 2/3
barrier than the 2.6/2.7 barrier. But it is still quite achievable, with
a little extra effort.

But you know that even better than I -- I take my hat off to you for
supporting all the way back to Python 2.3, that is far more dedicated
than I am.

In my experience, such as it is, the hard part about writing code that
works from 2.4 to 3.4 is not the 3 versions but the 2.4 and 2.5 versions.

It's an extreme case, but the latest released version of coverage.py
supports Python 2.3 through 3.3 with one code base. To do it, there's a
compatibility layer (akin to six). Then you stay away from features
that aren't available on all versions. In a few places, you might need
to have version checks, and the code can get a little idiomatic to
continue to work.

It's a tradeoff: you have to decide for yourself whether the effort is
worth the benefit. I was glad to be able to drop support for 2.3, 2.4,
and 2.5, and now only support 2.6-3.4 in coverage.py.

Sounds like your experience agrees with mine.

 

[Steven D'Aprano]

That very realization helped me wean myself from "print." Its sole
raison d'être is the insertion of the newline, which it would be nicer
to micromanage anyway; that's how it's done in other programming
languages as well: C, perl, guile, ... (Well, ok, "echo" is the
exception.)

echo is not "the" exception. *Many* languages handle the newline when
printing: Pascal, Ruby, Io, Dylan, Haskell, Rebol, Tcl, Perl6, Java,
Ocaml, ... either add a newline by default, or provide two functions for
printing, one which adds newline and one which doesn't.

The rule of three applies here: anything you do in three different places
ought to be managed by a function. Printing a newline at the end of a
line of output is *incredibly* common. Any language which fails to
provide a print-with-newline function is, frankly, sub-standard.

 

[Ned Batchelder]

How bizarre. I've been looking forward with great pleasure to Fedora
moving to Python 3 as the standard system Python, expecting that this
move from one of the big distros will start a chain reaction of others
doing the same thing. Perhaps Arch-Linux is guilty of being prematurely
Python 3, a little like those people hauled up to explain themselves to
the House Unamerican Activities Committee to explain why they were a
"premature anti-fascist".

My understanding is that Fedora's move will not include making the word
"python" mean Python 3. Their move means that Python 3 will be
installed by default, and that their Python programs that are part of
the distro will be Python 3 programs. They can still refer to it as
"python3".

I have no idea what "our pain" you are referring to, or who "our" refers
to. In the three or five years or so since Arch-Linux moved to Python 3
by default, I don't recall ever seeing even a single email from somebody
confused by Arch-Linux's move, not here, or on the tutor mailing list, or
on Python-Dev or Python-Ideas. Nor have I seen any signs of difficulty or
confusion on Python-related blogs, or StackOverflow.

In the #python IRC channel, there's a steady flow of people who run
programs they find online, and they get a syntax error on "print", and
we say, "Arch?" and they say, "yup".

Perhaps I overstated the amount of pain. But Arch's move prompted a PEP
to be written explaining what the word "python" should mean:

http://python.org/dev/peps/pep-0394/

Note that they say there that "for the time being" the word python
should mean Python 2, anticipating that eventually it will be OK to
change it to Python 3. But I think that change would always cause
confusion, and we should not change it over. I understand that this is
a controversial view, and don't hold it strongly enough to defend it.

That's not to say that there has been absolutely none at all. The
Internet is a big place, and I daresay I've missed something. But given
how small the Arch-Linux share of the Linux space is, I would be
astonished if their move caused more than a tiny little ripple. Perhaps a
paper-cut worth of pain.

It caused enough of a ripple to get PEP 394 written so that people
wouldn't do it again.

I expect that there have been far more angry

 

[Roy Smith]

The rule of three applies here: anything you do in three different places
ought to be managed by a function.

I prefer the rule of two

 

[Chris Angelico]

Perhaps Arch-Linux is guilty of being prematurely Python 3...

I have no idea what "our pain" you are referring to, or who "our" refers
to. In the three or five years or so since Arch-Linux moved to Python 3
by default, I don't recall ever seeing even a single email from somebody
confused by Arch-Linux's move, not here, or on the tutor mailing list, or
on Python-Dev or Python-Ideas. Nor have I seen any signs of difficulty or
confusion on Python-related blogs, or StackOverflow.

That's not to say that there has been absolutely none at all.

There definitely has been a little. Scripts that began with a "python"
shebang and assumed 2.x would suddenly fail on Arch. But not a huge
amount of confusion. I expect that there'll be a progressive shift -
more distros will start shipping 3.x under the name "python", so
script authors will be more and more aware of the difference, and
before long we'll settle on explicit use of "python2" or "python3" for
anything that matters. Think of the bug reports: "Your program doesn't
work on Ubuntu 14.04, but change the shebang and it'll work, without
breaking it for anything else". Easy fix. And then once Debian and Red
Hat move to 3.x as the default system Python, everyone'll use
"python2" for 2.7 (by that time, I doubt 2.6 or earlier will be
supported much anywhere) and "python" for 3.x, and the transition will
be complete.

ChrisA

 

[Chris Angelico]

The rule of three applies here: anything you do in three different places
ought to be managed by a function. Printing a newline at the end of a
line of output is *incredibly* common. Any language which fails to
provide a print-with-newline function is, frankly, sub-standard.

I wouldn't go that far. There are plenty of languages where the
default (printf, write, werror, etc) doesn't add the newline, and I
wouldn't call the *language* sub-standard for that. But yes, it does
bug me now and then. I use my "say" function to produce one or more
lines of output in Gypsum, and it guarantees complete lines (because
the system works with lines, not streams of characters); and then if I
use the "werror" function to write to stderr, I have to remember to
add the newline. However, I think Py2's print statement has way too
many weirdnesses - the trailing comma (reminiscent of BASIC, where I
never liked it either), the whole "soft space" concept, etc. Py3's
print function, with the keyword end="", is a lot better, though still
a tad verbose. (I don't know of any solution to that.)

ChrisA

 

[Ned Batchelder]

My understanding is that Fedora's move will not include making the word
"python" mean Python 3. Their move means that Python 3 will be
installed by default, and that their Python programs that are part of
the distro will be Python 3 programs. They can still refer to it as
"python3".

From http://fedoraproject.org/wiki/Changes/Python_3_as_Default :

Users shouldn't notice any changes, ... /usr/bin/python will still
point to Python 2 and depending on result of discussions with FPC,
"yum install python-foo" will still install Python 2 version of
the package.

 

[Ethan Furman]

In my experience, such as it is, the hard part about writing code that
works from 2.4 to 3.4 is not the 3 versions but the 2.4 and 2.5 versions.

+1000! (yes, that's factorial

 

[Chris Angelico]

I prefer the rule of two

The way I explain it is: Three is a rule of thumb. Sometimes it's
blatantly obvious at two, and other times you need four or five
similar pieces of code before you can see which part should become the
function. If the code's absolutely identical and reasonably
long/complex, then yes, two's all you need, but how often is that?
Usually it's similar, rather than congruent... err I mean identical.
That's where the third usage comes in. Or if it's maybe 2-3 lines,
used in two places, it doesn't necessarily need to be a function.
Again, a third usage is a strong hint that it should be broken out.

The rule doesn't say that anything that *isn't* in three places yet
should *not* be broken out.

ChrisA