newbie ``print`` question

[Chris Angelico]

Thanks again, Terry. There is a lot to the language, I am finding
out. I am a HW engineer, not really a programmer. Python seems a lot
more sophisticated than MATLAB.

I'm kinda thinking `write` is likely to be a little more "stable" than
`print` (if that is the right characterization) when my eventual
switch from 2.7 to 3.x happens. You think?

If you're planning to switch, make use of __future__. It's
specifically to make that job easier. Once you have a future
declaration at the top, print() will be stable across 2.7 and 3.x.

ChrisA

 

[MRAB]

Sorry, I was a little vague on the newline stuff.

In any case, I've learned I should probably avoid the comma, if
looking at 3.x:

a=1.0,
(None,)
b=2.0

Explanation:

With 'print' as a function, the first 'print' prints the result of
"'a=%.1f,' % 1.0" and then returns None. The trailing comma makes that
into a tuple (None,), which is printed by the interactive interpreter
as such.

In other words:

The second prints the result of "'b=%.1f' % 2.0" and then returns None.
The interactive interpreter, recognising that it's only None, doesn't
bother to print it.

In other words:

 

[gwhite]

If you're planning to switch, make use of __future__. It's
specifically to make that job easier. Once you have a future
declaration at the top, print() will be stable across 2.7 and 3.x.

I guess you're saying 3.x will just ignore:

from __future__ import print_function

I'll risk being silly, and thus ask: but what if when I get to 3.x
there is no __future__, as it is now "present?" Do I need to strip
out the line?

What would happen when I finally started running 3.3, and a new
__future__ was made that broke the old syntax? Do I need to strip out
the line?

I'm probably over thinking it. I don't know what I am doing. lol!

 

[Chris Angelico]

I guess you're saying 3.x will just ignore:

from __future__ import print_function

I'll risk being silly, and thus ask: but what if when I get to 3.x
there is no __future__, as it is now "present?" Do I need to strip
out the line?

What would happen when I finally started running 3.3, and a new
__future__ was made that broke the old syntax? Do I need to strip out
the line?

I'm probably over thinking it. I don't know what I am doing. lol!

The __future__ statement is guaranteed to be supported forever
afterwards. And new ones won't do anything unless you explicitly put
them into your code. It's quite a good system, imo.

ChrisA

 

[gwhite]

Explanation:

With 'print' as a function, the first 'print' prints the result of
"'a=%.1f,' % 1.0" and then returns None. The trailing comma makes that
into a tuple (None,), which is printed by the interactive interpreter
as such.

In other words:

 >>> None,
(None,)
 >>>

The second prints the result of "'b=%.1f' % 2.0" and then returns None.
The interactive interpreter, recognising that it's only None, doesn't
bother to print it.

In other words:

 >>> None

Thanks, that makes sense.

It does look like 2.7 & 3.3 don't parse the comma the same way. Just
to repeat, since I didn't give the exact same line to both versions of
Python:

2.7a=1.0, b=2.0

This has been more informative than I thought it was going to be.

 

[MRAB]

Thanks, that makes sense.

It does look like 2.7 & 3.3 don't parse the comma the same way. Just
to repeat, since I didn't give the exact same line to both versions of
Python:

2.7
a=1.0, b=2.0

This has been more informative than I thought it was going to be.

Basically:

In Python 2, 'print' is a statement.
In Python 3, 'print' is a function.

so they _would_ be parsed differently, because they _are_ different.

However, in later versions of Python 2, such as 2.7, adding "from
__future__ import print_function" will make 'print' a function like in
Python 3. (It has no effect in Python 3 because 'print' is already a
function, of course, so if you've converted a Python 2 script which
contains it to Python 3 and just happened to leave it in, it won't
complain either.)