are final newlines appended if output lacks it?

[Tim Peters]

[Bengt Richter]
> So is the goal is to guarantee a final EOL if the last output to
> sys.stdout was from a print?

I don't know, but that appears to be the intent of the code.

> (Apparently sys.stdout.write() resets sys.stdout.softspace
> unconditionally,

Yes.

> so it's allowed to have the last word with no tack-ons,
> but a final print with a trailing comma will get its softspace
> turned to an EOL?

Looks that way, yes.

> I guess this is just policy, and not related to the apparent
> (IMO) bug that confuses interactive echo with program output
> to stdout, so that interactive echo of a typed line end
> erroneously (IMO) resets sys.stdout.softspace.

Heh -- I couldn't parse that.  If you think you have a bug, and you care
about it, please open a bug report on SourceForge.

> Note:
>
>  >>> import sys
>  >>> class SO:
>  ...     def write(self,s): sys.stderr.write(`s`+'\n')
>  ...
>  >>> sys.stdout = SO()
>  >>> print sys.stdout.softspace,; print sys.stdout.softspace,
>  '0'
>  ' '
>  '1'
>  '\n'

Python calls Py_FlushLine() (I showed the source before) after interpreting
each block it reads from the shell.  This was one block of input, so
Py_FlushLine was called once after the entire block completed, and because
the block left sys.stdout.softspace true, Py_FlushLine() wrote a newline to
sys.stdout and cleared sys.stdout.softspace.

>  >>> print sys.stdout.softspace,; print sys.stdout.softspace
>  '0'
>  ' '
>  '1'
>  '\n'

Ditto.

>  >>> def foo():
>  ...     print sys.stdout.softspace,; print sys.stdout.softspace,
>  ...     print sys.stdout.softspace,; print sys.stdout.softspace,
>  ...

This block didn't set sys.stdout.softspace, so Py_FlushLine didn't do
anything when the interpretation of the block completed.

>  >>> foo()
>  '0'
>  ' '
>  '1'
>  ' '
>  '1'
>  ' '
>  '1'
>  '\n'

This block left sys.stdout.softspace set when the block (the call to foo())
completed, so Py_FlushLine did write a newline to sys.stdount (and cleared
sys.stdout.softspace).

> Note that the interactive call to foo() only echoed one EOL, so the
> softspace from the first print line survived to influence the second line
> inside foo, unlike for the separate invocations preceding.

Yes, there's one call to Py_FlushLine per interactive block, after the block
completes executing.  The number of Python statements executed per
interactive block makes no difference.

> If the interactive _echo_ is actually going to sys.__stdout__

I'm not sure what "interactive echo" means, but under the only plausible
meanings I can think of, it would be out of Python's hands, controlled by
however your platform C's (and possible GNU readline, if you're using that)
reading from stdin interacts with the console device.  Python isn't trying
to echo, or not to echo, anything you type.  Python prints interactive
*prompts* ('>>> ' and '... ') to C's idea of what stderr means.

> when normal sys.stdout is redirected, perhaps sys.__stdout__.softspace
> should be reset for the interactive EOL echo instead of
> sys.stdout.softspace?

There is no "interactive EOL echo" in a sense I can grok.  Python is
apparently trying to make sure that the output produced by print statements,
to sys.stdout, produced by each interactive block, ends with a newline, and
that's all.  Whether the EOLs (or anything else) you type get echoed is a
function of your console device, and don't affect sys.stdout.softspace
either way.