running python 2 vs 3

[Rustom Mody]

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.

Ned is talking to (and from) a lib-writer perspective
Marko is talking from noob perspective (which is what the OP looks like)

Good to choose our hats appropriately

 

[alex23]

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

On 21/03/2014 8:05 AM, Terry Reedy wrote:
3. [...]

"Our chief weapon is..."

 

[Steven D'Aprano]

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

When you install random programs you find online without going through
your package manager, you have no guarantee that all the dependencies
will be met. Particularly of third-party libraries, but also of standard
Python libraries too:

http://bytes.com/topic/python/answers/448757-how-enable-rotor-python-2-4-2-a

If your script uses xreadlines, rotor, or mpz, using "python" to refer to
both pre-2.4 and post-2.4 will cause breakage. Likewise, I've seen Python
2.6 break applications because it removed string exceptions. So I'm not
seeing anything out of the ordinary with Arch: any version change has the
possibility to break scripts. Python 3 is just more obvious because of
the change to print, which I daresay is a little more common than rotor...

Arch happens to be at the bleeding edge of that, bless them, but if you
use Arch, that's what you're letting yourself into. You know what they
say -- even Slackware users think Arch users are nuts

I've also seen scripts broken because the script used a hard-coded path
to the Python executable, like /usr/bin/python or /usr/local/bin/python. Or
because they've hard-coded the version number. Or because they didn't
hard-code the version number. I haven't seen scripts broken because "env"
has moved, but I guess that's only a matter of time. Frankly, hash-bang
lines are a dirty hack, and like all dirty hacks, they work really well
until they suddenly don't.

 

[Chris Angelico]

I haven't seen scripts broken because "env"
has moved, but I guess that's only a matter of time.

That usage is extremely common, and isn't it also specified by POSIX?
I think that's about as dependable as you can get.

Course, it does depend on the user's $PATH...

ChrisA

 

[Marko Rauhamaa]

go for the lowest common denominator:

print("some single string")

which works happily in all versions of Python.

Whenever I have used "print" in my code, it has been with a >>
redirection.


Marko

 

[Chris Angelico]

Whenever I have used "print" in my code, it has been with a >>
redirection.

Then you're probably not using "sys.stdout.write" but some other file
object's write method.

Also, I find it highly unusual that you never use print in its most
basic and intended form.

ChrisA

 

[Marko Rauhamaa]

Then you're probably not using "sys.stdout.write" but some other file
object's write method.

Correct, sys.stderr.write would have been a more accurate choice.

Also, I find it highly unusual that you never use print in its most
basic and intended form.

Printing to the stdout (hardcoded) is a relatively rare need. Mostly,
I've used "print" for diagnostic messages, and whenever I've had to
create actual output, I've parameterized the target object.


Marko

 

[Rustom Mody]

Chris Angelico :

Correct, sys.stderr.write would have been a more accurate choice.

Printing to the stdout (hardcoded) is a relatively rare need. Mostly,
I've used "print" for diagnostic messages, and whenever I've had to
create actual output, I've parameterized the target object.

Hear Hear!
Ive no opinion on whether python 2 or 3 print is better.

However I believe that people trying to help noobs would be actually
more helpful if they indicated that using prints all over code is not kosher.

Then whats the use/sense of print?? Debugging...

 

[Mark Lawrence]

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

Everybody, and especially Antipodeans, knows that there is no rule 6 and
by definition what rule 7 is