running python 2 vs 3

M

Mark H Harris

#!/usr/bin/env python

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

It gets tricky for distribution (you need docs for your distros, imho)
because #!/usr/bin/env python means different things on different
systems.

I actually have three major versions of python2 and 2 major versions of
python3 on my primary system at this point. On my machine python2.6 is
"python". That is because that system shipped with 2.6 and many of the
subsystem stuff depends on python2.6 /

When I call python2 that means python2.7.6 /

When I call python3 that means python3.3.4 /

I can also call python2.7, which is 2.7.2 /

You get the idea. There is no one set rule, because there are many
distros (gnu/linux) that use python at various versions, and they all us
different setups. Really , you need an install script to snoop out the
configurables.

marcus
 
M

Mark Lawrence

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

I do not agree that the dialects are too far apart, not that it really
matters. There are several libraries available to enable code to run
under both versions. The starter is 2to3 which had been in the standard
library for what seems like an eternity to me.
 
N

Ned Batchelder

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



With Arch-Linux, python is python3...

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

Ned Batchelder

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.

Plenty of people have adopted a dual-support strategy, with one code
base that supports both Python 2 and Python 3. The six module can help
a great deal with this.
 
M

Marko Rauhamaa

Mark Lawrence said:
The starter is 2to3 which had been in the standard library for what
seems like an eternity to me.

No problem there. It helps you transition from python2 to python3.

However, python3 is here and you should be able to write genuine python3
code with the appropriate bytes and string facilities. It would be very
confusing to try to mix the two regimes.

I must say, though, that Python3 destroyed "print" forever for me. To
avoid nausea, I write sys.stdout.write() in all Python3 code.


Marko
 
D

Dan Stromberg

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

Actually, I formerly used /usr/bin/env, but have recently (within the
last couple of years) stopped.

This is because the env trick doesn't play nicely with top IME. Also,
it's a trick.
 
M

Marko Rauhamaa

Ned Batchelder said:
Plenty of people have adopted a dual-support strategy, with one code
base that supports both Python 2 and Python 3. The six module can help
a great deal with this.

I wonder how easy the resulting code is to the eyes and how easy it is
for the casual maintainer to accidentally break the delicate balance. In
a word, I wouldn't go there. Stay with Python2 as long as you must and
then, migrate and leave it behind.


Marko
 
Z

Zachary Ware

I must say, though, that Python3 destroyed "print" forever for me. To
avoid nausea, I write sys.stdout.write() in all Python3 code.

To each their own :). I can't stand using 'print' as a statement.
It's a very nice trick to be able to write a script, think "oh, all
those prints should really be sending that output somewhere else", and
then instead of changing every individual print, just define a
different 'print' function at the top of the file (which may be as
simple as `print = functools.partial(print, file=sys.stderr)` or
`print = logging.debug`).
 
M

Mark Lawrence

No problem there. It helps you transition from python2 to python3.

However, python3 is here and you should be able to write genuine python3
code with the appropriate bytes and string facilities. It would be very
confusing to try to mix the two regimes.

I must say, though, that Python3 destroyed "print" forever for me. To
avoid nausea, I write sys.stdout.write() in all Python3 code.

Not for me, I was using from __future__ import print_function for years
so got used to typing those two extra brackets, plus print very kindly
inserts the newlines for me.
 
M

Marko Rauhamaa

Dan Stromberg said:
Actually, I formerly used /usr/bin/env, but have recently (within the
last couple of years) stopped.

This is because the env trick doesn't play nicely with top IME. Also,
it's a trick.

I'm not sure I like it either, but it's a standard idiom in Pythonland.


Marko
 
M

Marko Rauhamaa

Mark Lawrence said:
Not for me, I was using from __future__ import print_function for
years so got used to typing those two extra brackets, plus print very
kindly inserts the newlines for me.

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


Marko
 
N

Ned Batchelder

I wonder how easy the resulting code is to the eyes and how easy it is
for the casual maintainer to accidentally break the delicate balance. In
a word, I wouldn't go there. Stay with Python2 as long as you must and
then, migrate and leave it behind.

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

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

Marko Rauhamaa

Ned Batchelder said:
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.

Well, with proper care, I suppose the same code base could support perl
as well. ;)


Marko
 
N

notbob

On 3/20/14 3:07 PM, Eric Jacoboni wrote:
Yes, and they have been told many times that this was foolish and wrong,
but it persists, much to our pain.

I've read that 2.7 is the defacto std for python (default on Slack
14.1). I installed py3 on Slack box cuz I'd gotten the little
"Programming the Raspberry Pi" book, which is a pretty good lil' book,
clarifying many confusing (to me) python issues. Only prob is, it's
fer python 3x. I guess I coulda kept the two platforms separate, but
then raspi has 2X and 3x, also, so I guess I need to get this issue
straight in my feeble geezer head, right outta the gate. I'm plum
grateful to all you kind folks who are taking the time to educate this
slow ol' curmudgeon. ;)

nb
 
N

notbob

When I call python2 that means python2.7.6 /

When I call python3 that means python3.3.4 /

I can also call python2.7, which is 2.7.2 /

You get the idea. There is no one set rule, because there are many
distros (gnu/linux) that use python at various versions, and they all us
different setups. Really , you need an install script to snoop out the
configurables.

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

nb
 
N

Ned Batchelder

Well, with proper care, I suppose the same code base could support perl
as well. ;)

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

Mark Lawrence

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


Marko

The end keyword argument to the print function defaults to newline but
you can make it anything you like, see
http://docs.python.org/3/library/functions.html#print
 
M

Michael Torrie

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)?'

If you want to run a script with python3, just invoke the python3
interpreter:

python3 blah.py
 
M

Mark H Harris

No wonder the latest O'Reilly book, Learning Python, 5th ed,
is 1600 pgs. I coulda swore someone sed python is easy. ;)

Python is easy, but its not simple.
Python is elegant, and full of art, but it has no paucity of constructs,
types, and opportunities for confusion.

My goal for designing SimplyPy (for instance)is to present the beautiful
heart of python (as Mark Summerfield calls it) and subsume the
complexities of the fulness of python within a simple interface, BUT
without limiting it.

Python is easy enough to teach children (I've done it), but its
"complete and elegant enough" for the most scientific of professionals.

You do not need to know the fulness of python in order to use it. It is
possible (even elegant) to use python (in a Rexx style) not at all
recognized as "pythonized" code, and yet very very simple and powerful.

The beauty of python, in my view, is the flexibility and extensibility
of the namespace with something more than the minimalist approach of
Lisp, BUT with the elegance of the language called python.

Get Mark Summerfield's Programming Python 3. Its really quite good, and
in my opinion better that the O'Reilly book, especially for new users.

Just an opinion of course.

marcus
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,077
Messages
2,570,567
Members
47,203
Latest member
EmmaSwank1

Latest Threads

Top