are final newlines appended if output lacks it?

[Tim Peters]

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

> ...
> I suspect the flush at the end of a block of input should only
> flush the buffers,

This business about flushing buffers is repeated several times.  Here's the
source of Py_FlushLine() again:

int
Py_FlushLine(void)
{
	PyObject *f = PySys_GetObject("stdout");
	if (f == NULL)
		return 0;
	if (!PyFile_SoftSpace(f, 0))
		return 0;
	return PyFile_WriteString("\n", f);
}

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.

> ...
> Would it break code to change the flush logic?

Of course.

> Maybe such code should break ;-)

Not unless there are compelling advantages to be gained by breaking 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().

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