are final newlines appended if output lacks it?

[Bengt Richter]

On Sun, 04 May 2003 20:46:44 -0400, Tim Peters <tim.one at comcast.net> wrote:

>[Bengt Richter, arguing about softspace]
>
>I don't agree there's a bug here, because the code seems clearly to be
>functioning as designed.  You can argue that the design is wrong, and then

Ok, if the following is as designed, then I'll argue it's wrong ;-)

 [22:20] C:\pywk\clp>python >z
 Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)
 Type "help", "copyright", "credits" or "license" for more inf
 >>> print 123
 >>> print 123
 >>> print 123,
 >>> print 123,
 >>> if 1:
 ...     print 456,
 ...     print 456,
 ...     print 456,
 ...
 >>> print 'xxx'
 >>> ^Z
 
 
 [22:35] C:\pywk\clp>type z
 123
 123
 123
 123
 456 456 456
 xxx
 
 [22:35] C:\pywk\clp>cat |python >z2
 print 123
 print 123
 print 123,
 print 123,
 if 1:
     print 456,
     print 456,
     print 456,
 
 print 'xxx'
 ^Z
 
 [22:37] C:\pywk\clp>type z2
 123
 123
 123 123 456 456 456 xxx
 
IMO z and z2 should have been equivalent outputs.
The screen echo for the input is the same either way,
and ISTM z2 is the output you'd expect from reading
either of the (identically echoed) inputs logs.

Making nice on the screen when the output is interlaced
should IMO not sacrifice the integrity of the programmed
output. ISTM it's just a matter of knowing when a prompt
needs to be preceded by a newline (but as part of the prompt,
not part of the stdout data, which per se should not be
interfered with).

>you're in PEP territory, arguing for a different-- and
>incompatible --design.  So write a PEP if you feel strongly about this.  I
>can't make more time for this topic.
>
Sorry. I wouldn't normally have gotten into this either, except my gut feel
is that z and z2 being different above is wrong. (Plus my original take
on the problem was wrong ;-)

[ ... Py_FlushLine code ...]
>Despite its name, it doesn't flush any buffers, the *only* things it does
>are (a) write a newline if sys.stdout.softspace is true; and, (b) clear
>sys.stdout.softspace.  If sys.stdout happens to be a line-buffered file,
>then writing a newline should flush it, of course.
>
>> ...
>> Not resetting softspace will mean a possible leading space on a line
>> from a subsequent print statement. That is good! It shows what was
>> actually pending in the output sequence.
>
>Regardless, it would be incompatible behavior, so won't be changed without
>an important use case.  I should note that I haven't seen any use cases in
>your posts about this, just arguments that "it's wrong".  So note that if
>you write a PEP, it will need compelling use cases to justify changing
>behavior.
Nothing compelling, just the example above. It's only compelling in rare
aesthetically charged moods ;-) It's not like I can't work around it ;-)
[...]
>> Isn't softspace logically just about concatenating successive
>> print statement outputs (with convenience resetting by stdout.write)?
>> And shouldn't the result be independent of whether (and how chunked)
>> those statements were executed interactively, if stdout is redirected?
>
>I don't know -- I didn't design it and can't recall ever caring about it.
>If I did care and disliked the current behavior, I'd stay away from "print",
>which-- as noted before --is normally the only thing that ever sets
>softspace.  If you want total WYSIWYG behavior, stick to sys.stdout.write().
>
I think the print softspace logic is ok, it's interfering with it in the stdout
output stream that's not ;-) Look what happens if we use stderr and its softspace:

 >>> import sys
 >>> print >> sys.stderr, 123,
 123>>> print >> sys.stderr, 123,
  123>>> print >> sys.stderr, 123,
  123>>> print >> sys.stderr, 123,
  123>>> print >> sys.stderr, 123
  123
 >>> print >> sys.stderr, 123
 123
 >>> print >> sys.stderr, 123
 123

The stderr output stream is intact, because Py_Flushline is hardcoded to stdout,
but for that reason there's also no prettifying extra newlines to keep the prompts
at the left (which could be done without clobbering the softspace logic).
>It's certainly the case that GUIs like IDLE rely on the current behavior to
>keep their (redirected!) version of sys.stdout looking nice; e.g., look at
Maybe someone will want to make stderr intertwingle nicely too, and the change
can be worked in.

>code.py's InteractiveInterpreter.runcode(), and you'll see that it emulates
>the same kind of newline-appending logic, via code.py's more-aptly (than
>Py_FlushLine) named softspace() function.
>
I'm not arguing against inserting extra newlines for the console, just not
by clobbering softspace logic ;-)

(BTW, if both stdout and stderr are going to the console, I guess there
might be more complications in deciding whether a prompt needs a prefixed newline ;-)

Regards,
Bengt Richter