Title: Omit printing newline after newline
Author: firstname.lastname@example.org (Guido van Rossum)
Type: Standards Track
Currently, the print statement always appends a newline, unless a
trailing comma is used. This means that if we want to print data
that already ends in a newline, we get two newlines, unless
special precautions are taken.
I propose to skip printing the newline when it follows a newline
that came from data.
In order to avoid having to add yet another magic variable to file
objects, I propose to give the existing 'softspace' variable an
extra meaning: a negative value will mean "the last data written
ended in a newline so no space *or* newline is required."
When printing data that resembles the lines read from a file using
a simple loop, double-spacing occurs unless special care is taken:
>>> for line in open("/etc/passwd").readlines():
... print line
While there are easy work-arounds, this is often noticed only
during testing and requires an extra edit-test roundtrip; the
fixed code is uglier and harder to maintain.
In the PRINT_ITEM opcode in ceval.c, when a string object is
printed, a check is already made that looks at the last character
of that string. Currently, if that last character is a whitespace
character other than space, the softspace flag is reset to zero;
this suppresses the space between two items if the first item is a
string ending in newline, tab, etc. (but not when it ends in a
space). Otherwise the softspace flag is set to one.
The proposal changes this test slightly so that softspace is set
-1 -- if the last object written is a string ending in a
0 -- if the last object written is a string ending in a
whitespace character that's neither space nor newline
1 -- in all other cases (including the case when the last
object written is an empty string or not a string)
Then, the PRINT_NEWLINE opcode, printing of the newline is
suppressed if the value of softspace is negative; in any case the
softspace flag is reset to zero.
This only affects printing of 8-bit strings. It doesn't affect
Unicode, although that could be considered a bug in the Unicode
implementation. It doesn't affect other objects whose string
representation happens to end in a newline character.
This change breaks some existing code. For example:
print "Subject: PEP 259\n"
In current Python, this produces a blank line separating the
subject from the message body; with the proposed change, the body
begins immediately below the subject. This is not very robust
code anyway; it is better written as
print "Subject: PEP 259"
In the test suite, only test_StringIO (which explicitly tests for
this feature) breaks.
A patch relative to current CVS is here:
The user community unanimously rejected this, so I won't pursue
this idea any further. Frequently heard arguments against
- It it likely to break thousands of CGI scripts.
- Enough magic already (also: no more tinkering with 'print'
This document has been placed in the public domain.