Abstract

Currently, theprint statement always appends a newline, unless atrailing comma is used. This means that if we want to print datathat already ends in a newline, we get two newlines, unlessspecial precautions are taken.

I propose to skip printing the newline when it follows a newlinethat came from data.

In order to avoid having to add yet another magic variable to fileobjects, I propose to give the existing ‘softspace’ variable anextra meaning: a negative value will mean “the last data writtenended in a newline so no spaceor newline is required.”

Problem

When printing data that resembles the lines read from a file usinga simple loop, double-spacing occurs unless special care is taken:

>>>forlineinopen("/etc/passwd").readlines():...printline...root:x:0:0:root:/root:/bin/bashbin:x:1:1:bin:/bin:daemon:x:2:2:daemon:/sbin:(etc.)>>>

While there are easy work-arounds, this is often noticed onlyduring testing and requires an extra edit-test roundtrip; thefixed code is uglier and harder to maintain.

Proposed Solution

In thePRINT_ITEM opcode inceval.c, when a string object isprinted, a check is already made that looks at the last characterof that string. Currently, if that last character is a whitespacecharacter other than space, the softspace flag is reset to zero;this suppresses the space between two items if the first item is astring ending in newline, tab, etc. (but not when it ends in aspace). Otherwise the softspace flag is set to one.

The proposal changes this test slightly so that softspace is setto:

• -1 – if the last object written is a string ending in anewline
• 0 – if the last object written is a string ending in awhitespace character that’s neither space nor newline
• 1 – in all other cases (including the case when the lastobject written is an empty string or not a string)

Then, thePRINT_NEWLINE opcode, printing of the newline issuppressed if the value of softspace is negative; in any case thesoftspace flag is reset to zero.

Scope

This only affects printing of 8-bit strings. It doesn’t affectUnicode, although that could be considered a bug in the Unicodeimplementation. It doesn’t affect other objects whose stringrepresentation happens to end in a newline character.

Risks

This change breaks some existing code. For example:

print"Subject: PEP 259\n"printmessage_body

In current Python, this produces a blank line separating thesubject from the message body; with the proposed change, the bodybegins immediately below the subject. This is not very robustcode anyway; it is better written as:

print"Subject: PEP 259"printprintmessage_body

In the test suite, onlytest_StringIO (which explicitly tests forthis feature) breaks.

Implementation

A patch relative to current CVS is here:

http://sourceforge.net/tracker/index.php?func=detail&aid=432183&group_id=5470&atid=305470

Rejected

The user community unanimously rejected this, so I won’t pursuethis idea any further. Frequently heard arguments againstincluded:

• It is likely to break thousands of CGI scripts.
• Enough magic already (also: no more tinkering with ‘print’please).

Copyright

This document has been placed in the public domain.