Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #28278 > unrolled thread

newbie ``print`` question

Back to article view | Back to comp.lang.python

Contents

  newbie ``print`` question gwhite <gwhite@ti.com> - 2012-09-02 10:23 -0700
    Re: newbie ``print`` question Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-02 18:41 +0100
    Re: newbie ``print`` question Joel Goldstick <joel.goldstick@gmail.com> - 2012-09-02 13:44 -0400
      Re: newbie ``print`` question gwhite <gwhite@ti.com> - 2012-09-02 12:46 -0700
    Re: newbie ``print`` question mblume <foobar@invalid.invalid> - 2012-09-02 17:49 +0000
      Re: newbie ``print`` question gwhite <gwhite@ti.com> - 2012-09-02 11:51 -0700
    Re: newbie ``print`` question Chris Rebert <clp2@rebertia.com> - 2012-09-02 10:55 -0700
      Re: newbie ``print`` question gwhite <gwhite@ti.com> - 2012-09-02 11:51 -0700
      Re: newbie ``print`` question gwhite <gwhite@ti.com> - 2012-09-02 12:26 -0700
        Re: newbie ``print`` question gwhite <gwhite@ti.com> - 2012-09-02 12:34 -0700
          Re: newbie ``print`` question Dave Angel <d@davea.name> - 2012-09-02 15:41 -0400
            Re: newbie ``print`` question gwhite <gwhite@ti.com> - 2012-09-02 12:50 -0700
              Re: newbie ``print`` question Dave Angel <d@davea.name> - 2012-09-02 16:15 -0400
                Re: newbie ``print`` question gwhite <gwhite@ti.com> - 2012-09-02 13:58 -0700
                  Re: newbie ``print`` question MRAB <python@mrabarnett.plus.com> - 2012-09-02 23:43 +0100
                    Re: newbie ``print`` question gwhite <gwhite@ti.com> - 2012-09-02 16:33 -0700
                      Re: newbie ``print`` question MRAB <python@mrabarnett.plus.com> - 2012-09-03 01:12 +0100
        Re: newbie ``print`` question Terry Reedy <tjreedy@udel.edu> - 2012-09-02 16:49 -0400
          Re: newbie ``print`` question gwhite <gwhite@ti.com> - 2012-09-02 14:18 -0700
            Re: newbie ``print`` question Chris Angelico <rosuav@gmail.com> - 2012-09-03 07:47 +1000
              Re: newbie ``print`` question gwhite <gwhite@ti.com> - 2012-09-02 16:20 -0700
                Re: newbie ``print`` question Chris Angelico <rosuav@gmail.com> - 2012-09-03 09:28 +1000
    Re: newbie ``print`` question Terry Reedy <tjreedy@udel.edu> - 2012-09-02 14:33 -0400
      Re: newbie ``print`` question gwhite <gwhite@ti.com> - 2012-09-02 12:18 -0700
    Re: newbie ``print`` question Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-02 16:37 -0400
      Re: newbie ``print`` question gwhite <gwhite@ti.com> - 2012-09-02 14:04 -0700

Page 1 of 2  [1] 2  Next page →

#28278 — newbie ``print`` question

I can't figure out how to stop the "add a space at the beginning"
behavior of the print function.

>>> print 1,;print 2,
1 2

See the space in between the 1 and the 2 at the output print to the
command console?

The help for print is:

"A space is written before each object is (converted and) written,
unless the output system believes it is positioned at the beginning of
a line."

So it is apparently doing what it is supposed to do.

Is there a way to stop this?  Or is there a different function that
will only print what you have in the formatted string?

For example, in MATLAB I only had to do:

>> fprintf('1');fprintf('2')
12

 fprintf works the same way if printing to a file.  It only puts in
what you explicitly tell it to put in.

[toc] | [next] | [standalone]

#28279

On 02/09/2012 18:23, gwhite wrote:
> I can't figure out how to stop the "add a space at the beginning"
> behavior of the print function.
>
>>>> print 1,;print 2,
> 1 2
>
> See the space in between the 1 and the 2 at the output print to the
> command console?
>
> The help for print is:
>
> "A space is written before each object is (converted and) written,
> unless the output system believes it is positioned at the beginning of
> a line."
>
> So it is apparently doing what it is supposed to do.
>
> Is there a way to stop this?  Or is there a different function that
> will only print what you have in the formatted string?
>
> For example, in MATLAB I only had to do:
>
>>> fprintf('1');fprintf('2')
> 12
>
>   fprintf works the same way if printing to a file.  It only puts in
> what you explicitly tell it to put in.
>

I'd settle for print 12, YMMV.

-- 
Cheers.

Mark Lawrence.

[toc] | [prev] | [next] | [standalone]

#28282

On Sun, Sep 2, 2012 at 1:23 PM, gwhite <gwhite@ti.com> wrote:
> I can't figure out how to stop the "add a space at the beginning"
> behavior of the print function.
>
>>>> print 1,;print 2,
> 1 2
>
> See the space in between the 1 and the 2 at the output print to the
> command console?
>
> The help for print is:
>
> "A space is written before each object is (converted and) written,
> unless the output system believes it is positioned at the beginning of
> a line."
>
> So it is apparently doing what it is supposed to do.
>
> Is there a way to stop this?  Or is there a different function that
> will only print what you have in the formatted string?

You can do it with string formatting.  My example shows 'old style'
string formatting syntax.  There is a newer style.  You can learn
about both from the online python docs.

>>> print "%d%d" % (1,2)
12
>>>

-- 
Joel Goldstick

[toc] | [prev] | [next] | [standalone]

#28304

On Sep 2, 10:45 am, Joel Goldstick <joel.goldst...@gmail.com> wrote:
> On Sun, Sep 2, 2012 at 1:23 PM, gwhite <gwh...@ti.com> wrote:
> > I can't figure out how to stop the "add a space at the beginning"
> > behavior of the print function.
>
> >>>> print 1,;print 2,
> > 1 2
>
> > See the space in between the 1 and the 2 at the output print to the
> > command console?
>
> > The help for print is:
>
> > "A space is written before each object is (converted and) written,
> > unless the output system believes it is positioned at the beginning of
> > a line."
>
> > So it is apparently doing what it is supposed to do.
>
> > Is there a way to stop this?  Or is there a different function that
> > will only print what you have in the formatted string?
>
> You can do it with string formatting.  My example shows 'old style'
> string formatting syntax.  There is a newer style.  You can learn
> about both from the online python docs.
>
>
>
> >>> print "%d%d" % (1,2)
> 12

For "real" stuff, I've been trying to use that.  I saw it in Beazley's
latest Essential text.

You're right, I can construct a single string and then write it.  In
fact, it looks like it is a must unless using the 3.2/3.3 version of
`print`.

[toc] | [prev] | [next] | [standalone]

#28283

Am Sun, 02 Sep 2012 10:23:53 -0700 schrieb gwhite:

> I can't figure out how to stop the "add a space at the beginning"
> behavior of the print function.
> 
>>>> print 1,;print 2,
> 1 2
> 
> See the space in between the 1 and the 2 at the output print to the
> command console?
> 
> The help for print is:
> 
> "A space is written before each object is (converted and) written,
> unless the output system believes it is positioned at the beginning of a
> line."
> 
> So it is apparently doing what it is supposed to do.
> 
> Is there a way to stop this?  Or is there a different function that will
> only print what you have in the formatted string?
> 
> For example, in MATLAB I only had to do:
> 
>>> fprintf('1');fprintf('2')
> 12
> 
>  fprintf works the same way if printing to a file.  It only puts in
> what you explicitly tell it to put in.

import sys

sys.stdout.write("1"); sys.stdout.write("2")


HTH
Martin

[toc] | [prev] | [next] | [standalone]

#28290

On Sep 2, 10:49 am, mblume <foo...@invalid.invalid> wrote:
> Am Sun, 02 Sep 2012 10:23:53 -0700 schrieb gwhite:
>
>
>
>
>
>
>
>
>
> > I can't figure out how to stop the "add a space at the beginning"
> > behavior of the print function.
>
> >>>> print 1,;print 2,
> > 1 2
>
> > See the space in between the 1 and the 2 at the output print to the
> > command console?
>
> > The help for print is:
>
> > "A space is written before each object is (converted and) written,
> > unless the output system believes it is positioned at the beginning of a
> > line."
>
> > So it is apparently doing what it is supposed to do.
>
> > Is there a way to stop this?  Or is there a different function that will
> > only print what you have in the formatted string?
>
> > For example, in MATLAB I only had to do:
>
> >>> fprintf('1');fprintf('2')
> > 12
>
> >  fprintf works the same way if printing to a file.  It only puts in
> > what you explicitly tell it to put in.
>
> import sys
>
> sys.stdout.write("1"); sys.stdout.write("2")
>
> HTH
> Martin

Thanks.

[toc] | [prev] | [next] | [standalone]

#28284

On Sun, Sep 2, 2012 at 10:23 AM, gwhite <gwhite@ti.com> wrote:
> I can't figure out how to stop the "add a space at the beginning"
> behavior of the print function.
>
>>>> print 1,;print 2,
> 1 2
>
> See the space in between the 1 and the 2 at the output print to the
> command console?
>
> The help for print is:
>
> "A space is written before each object is (converted and) written,
> unless the output system believes it is positioned at the beginning of
> a line."
>
> So it is apparently doing what it is supposed to do.
>
> Is there a way to stop this?

If you were to use Python 3.x, yes. Otherwise, no.

> Or is there a different function that
> will only print what you have in the formatted string?

Use the .write() method of the sys.stdout file object.
http://docs.python.org/library/sys.html#sys.stdout

Alternatively, you can stick with `print` and rework your code so that
it outputs an entire line at a time (thus, there'd only be 1 argument
passed to `print`, so its "spaces between arguments" feature wouldn't
come into play).

Cheers,
Chris

[toc] | [prev] | [next] | [standalone]

#28291

On Sep 2, 10:55 am, Chris Rebert <c...@rebertia.com> wrote:
> On Sun, Sep 2, 2012 at 10:23 AM, gwhite <gwh...@ti.com> wrote:
> > I can't figure out how to stop the "add a space at the beginning"
> > behavior of the print function.
>
> >>>> print 1,;print 2,
> > 1 2
>
> > See the space in between the 1 and the 2 at the output print to the
> > command console?
>
> > The help for print is:
>
> > "A space is written before each object is (converted and) written,
> > unless the output system believes it is positioned at the beginning of
> > a line."
>
> > So it is apparently doing what it is supposed to do.
>
> > Is there a way to stop this?
>
> If you were to use Python 3.x, yes. Otherwise, no.
>
> > Or is there a different function that
> > will only print what you have in the formatted string?
>
> Use the .write() method of the sys.stdout file object.http://docs.python.org/library/sys.html#sys.stdout
>
> Alternatively, you can stick with `print` and rework your code so that
> it outputs an entire line at a time (thus, there'd only be 1 argument
> passed to `print`, so its "spaces between arguments" feature wouldn't
> come into play).
>
> Cheers,
> Chris

Thanks.

[toc] | [prev] | [next] | [standalone]

#28297

On Sep 2, 10:55 am, Chris Rebert <c...@rebertia.com> wrote:
> On Sun, Sep 2, 2012 at 10:23 AM, gwhite <gwh...@ti.com> wrote:
> > I can't figure out how to stop the "add a space at the beginning"
> > behavior of the print function.
>
> >>>> print 1,;print 2,
> > 1 2
>
> > See the space in between the 1 and the 2 at the output print to the
> > command console?
>
> > The help for print is:
>
> > "A space is written before each object is (converted and) written,
> > unless the output system believes it is positioned at the beginning of
> > a line."
>
> > So it is apparently doing what it is supposed to do.
>
> > Is there a way to stop this?
>
> If you were to use Python 3.x, yes. Otherwise, no.
>
> > Or is there a different function that
> > will only print what you have in the formatted string?
>
> Use the .write() method of the sys.stdout file object.http://docs.python.org/library/sys.html#sys.stdout
>
> Alternatively, you can stick with `print` and rework your code so that
> it outputs an entire line at a time (thus, there'd only be 1 argument
> passed to `print`, so its "spaces between arguments" feature wouldn't
> come into play).

On the "rework" thing, yes, I suppose I could construct the line as a
single string prior to print.    There would be things like `for`
loops and conditionals to do so.  That isn't so unusual.

I was actually doing some simple tests of other things -- you know,
newbie stuff to make sure I understood what the various ops were
doing.  I wasn't even thinking about `print` Then I got sidetracked
with this item, which I thought was very odd, since it is "deciding
for you" to stuff a space in.

[toc] | [prev] | [next] | [standalone]

#28299

On Sep 2, 12:26 pm, gwhite <gwh...@ti.com> wrote:
> On Sep 2, 10:55 am, Chris Rebert <c...@rebertia.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Sun, Sep 2, 2012 at 10:23 AM, gwhite <gwh...@ti.com> wrote:
> > > I can't figure out how to stop the "add a space at the beginning"
> > > behavior of the print function.
>
> > >>>> print 1,;print 2,
> > > 1 2
>
> > > See the space in between the 1 and the 2 at the output print to the
> > > command console?
>
> > > The help for print is:
>
> > > "A space is written before each object is (converted and) written,
> > > unless the output system believes it is positioned at the beginning of
> > > a line."
>
> > > So it is apparently doing what it is supposed to do.
>
> > > Is there a way to stop this?
>
> > If you were to use Python 3.x, yes. Otherwise, no.
>
> > > Or is there a different function that
> > > will only print what you have in the formatted string?
>
> > Use the .write() method of the sys.stdout file object.http://docs.python.org/library/sys.html#sys.stdout
>
> > Alternatively, you can stick with `print` and rework your code so that
> > it outputs an entire line at a time (thus, there'd only be 1 argument
> > passed to `print`, so its "spaces between arguments" feature wouldn't
> > come into play).
>
> On the "rework" thing, yes, I suppose I could construct the line as a
> single string prior to print.    There would be things like `for`
> loops and conditionals to do so.  That isn't so unusual.
>
> I was actually doing some simple tests of other things -- you know,
> newbie stuff to make sure I understood what the various ops were
> doing.  I wasn't even thinking about `print` Then I got sidetracked
> with this item, which I thought was very odd, since it is "deciding
> for you" to stuff a space in.

btw, I also thought the default "add a CR LF" to the end was odd too.
But at least that one had a simple way out.

[toc] | [prev] | [next] | [standalone]

#28302

On 09/02/2012 03:34 PM, gwhite wrote:
> <snip>
>
> btw, I also thought the default "add a CR LF" to the end was odd too.
> But at least that one had a simple way out.

But it (print on Python 2.x) doesn't, unless you're stuck on Windows. 
And even then, you can prevent it by using a 'b' in the mode.

-- 

DaveA

[toc] | [prev] | [next] | [standalone]

#28306

On Sep 2, 12:43 pm, Dave Angel <d...@davea.name> wrote:
> On 09/02/2012 03:34 PM, gwhite wrote:
>
> > <snip>
>
> > btw, I also thought the default "add a CR LF" to the end was odd too.
> > But at least that one had a simple way out.
>
> But it (print on Python 2.x) doesn't, unless you're stuck on Windows.
> And even then, you can prevent it by using a 'b' in the mode.

Yes, I'm using windows.  What is "'b' in the mode?"  The help for
print says:

A ``'\n'`` character is written at the end, unless the ``print``
statement ends with a comma.  This is the only action if the statement
contains just the keyword ``print``.

So I followed with a comma to stop the default CR LF insertion.

[toc] | [prev] | [next] | [standalone]

#28311

On 09/02/2012 03:50 PM, gwhite wrote:
> On Sep 2, 12:43 pm, Dave Angel <d...@davea.name> wrote:
>> On 09/02/2012 03:34 PM, gwhite wrote:
>>
>>> <snip>
>>> btw, I also thought the default "add a CR LF" to the end was odd too.
>>> But at least that one had a simple way out.
>> But it (print on Python 2.x) doesn't, unless you're stuck on Windows.
>> And even then, you can prevent it by using a 'b' in the mode.
> Yes, I'm using windows.  What is "'b' in the mode?"  The help for
> print says:
>
> A ``'\n'`` character is written at the end, unless the ``print``
> statement ends with a comma.  This is the only action if the statement
> contains just the keyword ``print``.
>
> So I followed with a comma to stop the default CR LF insertion.
>

You're correct;  the best way to suppress the newline at the end of
print is to use the trailing comma.  But since print is for lines, it
usually is a good default.  If you don't want to get any extra
characters, just use write().  It takes a string, and outputs exactly
what it's given.

I assumed you were complaining about the conversion of newline to
carriage-return-newline, which is done by default on Windows, and can be
suppressed by opening the file with "b" as the mode parameter.



-- 

DaveA

[toc] | [prev] | [next] | [standalone]

#28320

On Sep 2, 1:16 pm, Dave Angel <d...@davea.name> wrote:
> On 09/02/2012 03:50 PM, gwhite wrote:
>
>
>
>
>
>
>
>
>
> > On Sep 2, 12:43 pm, Dave Angel <d...@davea.name> wrote:
> >> On 09/02/2012 03:34 PM, gwhite wrote:
>
> >>> <snip>
> >>> btw, I also thought the default "add a CR LF" to the end was odd too.
> >>> But at least that one had a simple way out.
> >> But it (print on Python 2.x) doesn't, unless you're stuck on Windows.
> >> And even then, you can prevent it by using a 'b' in the mode.
> > Yes, I'm using windows.  What is "'b' in the mode?"  The help for
> > print says:
>
> > A ``'\n'`` character is written at the end, unless the ``print``
> > statement ends with a comma.  This is the only action if the statement
> > contains just the keyword ``print``.
>
> > So I followed with a comma to stop the default CR LF insertion.
>
> You're correct;  the best way to suppress the newline at the end of
> print is to use the trailing comma.  But since print is for lines, it
> usually is a good default.  If you don't want to get any extra
> characters, just use write().  It takes a string, and outputs exactly
> what it's given.
>
> I assumed you were complaining about the conversion of newline to
> carriage-return-newline, which is done by default on Windows, and can be
> suppressed by opening the file with "b" as the mode parameter.


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:

>>> from __future__ import print_function
>>> print('a=%.1f,' % 1.0),;print('b=%.1f' % 2.0)
a=1.0,
(None,)
b=2.0

Given the input of several posters, I feel like I should probably be
using the `write` function anyway.   (I don't have a problem pre-
constructing strings either.)

But I am a newbie, and "all" the show-and-tell examples/tutorials use
`print`.  But this little thread has helped me a lot.

[toc] | [prev] | [next] | [standalone]

#28325

On 02/09/2012 21:58, gwhite wrote:
> On Sep 2, 1:16 pm, Dave Angel <d...@davea.name> wrote:
>> On 09/02/2012 03:50 PM, gwhite wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > On Sep 2, 12:43 pm, Dave Angel <d...@davea.name> wrote:
>> >> On 09/02/2012 03:34 PM, gwhite wrote:
>>
>> >>> <snip>
>> >>> btw, I also thought the default "add a CR LF" to the end was odd too.
>> >>> But at least that one had a simple way out.
>> >> But it (print on Python 2.x) doesn't, unless you're stuck on Windows.
>> >> And even then, you can prevent it by using a 'b' in the mode.
>> > Yes, I'm using windows.  What is "'b' in the mode?"  The help for
>> > print says:
>>
>> > A ``'\n'`` character is written at the end, unless the ``print``
>> > statement ends with a comma.  This is the only action if the statement
>> > contains just the keyword ``print``.
>>
>> > So I followed with a comma to stop the default CR LF insertion.
>>
>> You're correct;  the best way to suppress the newline at the end of
>> print is to use the trailing comma.  But since print is for lines, it
>> usually is a good default.  If you don't want to get any extra
>> characters, just use write().  It takes a string, and outputs exactly
>> what it's given.
>>
>> I assumed you were complaining about the conversion of newline to
>> carriage-return-newline, which is done by default on Windows, and can be
>> suppressed by opening the file with "b" as the mode parameter.
>
>
> 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:
>
>>>> from __future__ import print_function
>>>> print('a=%.1f,' % 1.0),;print('b=%.1f' % 2.0)
> 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:

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

> Given the input of several posters, I feel like I should probably be
> using the `write` function anyway.   (I don't have a problem pre-
> constructing strings either.)
>
> But I am a newbie, and "all" the show-and-tell examples/tutorials use
> `print`.  But this little thread has helped me a lot.
>

[toc] | [prev] | [next] | [standalone]

#28328

On Sep 2, 3:43 pm, MRAB <pyt...@mrabarnett.plus.com> wrote:
> On 02/09/2012 21:58, gwhite wrote:
>
>
>
>
>
>
>
> > On Sep 2, 1:16 pm, Dave Angel <d...@davea.name> wrote:
> >> On 09/02/2012 03:50 PM, gwhite wrote:
>
> >> > On Sep 2, 12:43 pm, Dave Angel <d...@davea.name> wrote:
> >> >> On 09/02/2012 03:34 PM, gwhite wrote:
>
> >> >>> <snip>
> >> >>> btw, I also thought the default "add a CR LF" to the end was odd too.
> >> >>> But at least that one had a simple way out.
> >> >> But it (print on Python 2.x) doesn't, unless you're stuck on Windows.
> >> >> And even then, you can prevent it by using a 'b' in the mode.
> >> > Yes, I'm using windows.  What is "'b' in the mode?"  The help for
> >> > print says:
>
> >> > A ``'\n'`` character is written at the end, unless the ``print``
> >> > statement ends with a comma.  This is the only action if the statement
> >> > contains just the keyword ``print``.
>
> >> > So I followed with a comma to stop the default CR LF insertion.
>
> >> You're correct;  the best way to suppress the newline at the end of
> >> print is to use the trailing comma.  But since print is for lines, it
> >> usually is a good default.  If you don't want to get any extra
> >> characters, just use write().  It takes a string, and outputs exactly
> >> what it's given.
>
> >> I assumed you were complaining about the conversion of newline to
> >> carriage-return-newline, which is done by default on Windows, and can be
> >> suppressed by opening the file with "b" as the mode parameter.
>
> > 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:
>
> >>>> from __future__ import print_function
> >>>> print('a=%.1f,' % 1.0),;print('b=%.1f' % 2.0)
> > 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:
>
>  >>> 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.7
>>> print('a=%.1f,' % 1.0),;print('b=%.1f' % 2.0)
a=1.0, b=2.0

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

[toc] | [prev] | [next] | [standalone]

#28329

On 03/09/2012 00:33, gwhite wrote:
> On Sep 2, 3:43 pm, MRAB <pyt...@mrabarnett.plus.com> wrote:
>> On 02/09/2012 21:58, gwhite wrote:
>>
>>
>>
>>
>>
>>
>>
>> > On Sep 2, 1:16 pm, Dave Angel <d...@davea.name> wrote:
>> >> On 09/02/2012 03:50 PM, gwhite wrote:
>>
>> >> > On Sep 2, 12:43 pm, Dave Angel <d...@davea.name> wrote:
>> >> >> On 09/02/2012 03:34 PM, gwhite wrote:
>>
>> >> >>> <snip>
>> >> >>> btw, I also thought the default "add a CR LF" to the end was odd too.
>> >> >>> But at least that one had a simple way out.
>> >> >> But it (print on Python 2.x) doesn't, unless you're stuck on Windows.
>> >> >> And even then, you can prevent it by using a 'b' in the mode.
>> >> > Yes, I'm using windows.  What is "'b' in the mode?"  The help for
>> >> > print says:
>>
>> >> > A ``'\n'`` character is written at the end, unless the ``print``
>> >> > statement ends with a comma.  This is the only action if the statement
>> >> > contains just the keyword ``print``.
>>
>> >> > So I followed with a comma to stop the default CR LF insertion.
>>
>> >> You're correct;  the best way to suppress the newline at the end of
>> >> print is to use the trailing comma.  But since print is for lines, it
>> >> usually is a good default.  If you don't want to get any extra
>> >> characters, just use write().  It takes a string, and outputs exactly
>> >> what it's given.
>>
>> >> I assumed you were complaining about the conversion of newline to
>> >> carriage-return-newline, which is done by default on Windows, and can be
>> >> suppressed by opening the file with "b" as the mode parameter.
>>
>> > 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:
>>
>> >>>> from __future__ import print_function
>> >>>> print('a=%.1f,' % 1.0),;print('b=%.1f' % 2.0)
>> > 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:
>>
>>  >>> 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.7
>>>> print('a=%.1f,' % 1.0),;print('b=%.1f' % 2.0)
> 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.)

[toc] | [prev] | [next] | [standalone]

#28318

On 9/2/2012 3:26 PM, gwhite wrote:

> On the "rework" thing, yes, I suppose I could construct the line as a
> single string prior to print.    There would be things like `for`
> loops and conditionals to do so.  That isn't so unusual.

The usual idiom is to construct a list of pieces and then join with ''.

 >>> print(''.join(['1', '2']))
12

Or map str to a list of objects.

 >>> print(''.join(map(str, [1, 2])))
12

You can do either of these in 2.x.
If you use .write, include '\n' at the end of the list (when needed).

Print was designed as a quick and easy way to put lines of text on the 
screen. Then people asked for a way to use with with other streams, 
hence the >> hack. Then people wanted ways to control the separator and 
terminator. As that point, Guido realized that it needed to be a 
function, not a statement, with all the options requested.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#28322

On Sep 2, 1:49 pm, Terry Reedy <tjre...@udel.edu> wrote:
> On 9/2/2012 3:26 PM, gwhite wrote:
>
> > On the "rework" thing, yes, I suppose I could construct the line as a
> > single string prior to print.    There would be things like `for`
> > loops and conditionals to do so.  That isn't so unusual.
>
> The usual idiom is to construct a list of pieces and then join with ''.
>
>  >>> print(''.join(['1', '2']))
> 12
>
> Or map str to a list of objects.
>
>  >>> print(''.join(map(str, [1, 2])))
> 12
>
> You can do either of these in 2.x.
> If you use .write, include '\n' at the end of the list (when needed).
>
> Print was designed as a quick and easy way to put lines of text on the
> screen. Then people asked for a way to use with with other streams,
> hence the >> hack. Then people wanted ways to control the separator and
> terminator. As that point, Guido realized that it needed to be a
> function, not a statement, with all the options requested.

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?

[toc] | [prev] | [next] | [standalone]

#28324

On Mon, Sep 3, 2012 at 7:18 AM, gwhite <gwhite@ti.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web