Print Changes Survive Criticism

08/30/2000

The comp.lang.python newsgroup erupted last week
with a flurry of posts that accused the Python development team of creeping
featurism, selling out the language to corporate interests, moving too fast, and
turning a deaf ear to the Python community. What triggered this lava flow of
accusations? The development team accepted a proposal to change the
syntax of the print statement.

The print statement is a very intuitive feature in Python and a good example of how Python is easy to learn. If you want to print something to the screen, you can just put what you want after the print command. Want to print several somethings? Separate them with commas. It's clear. It makes sense. Unfortunately it only prints to standard out, or more accurately, the sys.stdout file handle. "Standard out" is one of three common system file
handles used to communicate with a text-based console, like the DOS or Unix
prompt. Both standard out and standard error (used for reporting errors) print
to the console. Standard in is associated with your keyboard. These
associations break down a bit in graphic operating systems with no clear text-based console, but it is still an incredibly useful tool while learning to
program or on systems that use a console. If you need keyboard input in your
program, you read it from standard in. You want to print something, you print
it to standard out.

But you don't always want to print to standard out; sometimes you want to
print to a file, or some other device. With print as it was, you could only do
this by redirecting standard out with some separate function calls, or
abandoning the print command altogether and using a separate write function.
This was confusing, and some thought it inelegant. Barry Warsaw proposed in PEP
214 that print be modified to make it easier to redirect the output.
He proposed adding a special marker to print's syntax to signify that you
wanted the text printed to a file or some other file-like object with a write
function.

Warsaw's proposed marker >> became the bone of
contention. Some thought it ugly and too reminiscent of C++. Some thought
creating a new reserved word like "to" would be better, even though it could
break some code that used this previously unreserved word. Some preferred that
a new writeln() function be created to handle redirection. Some
thought it was unnecessary in any case and we should just stick with what we
have. But the design team liked it, blessed it and coded it into Python 2.0 as
the best solution. Several posters wondered, "Were they listening at all?" The
overall reaction to this on the newsgroup was worse than the reaction to the
CNRI license, maybe because that was something that CNRI was doing to the
Python community, but this >> thing was something done by
the beloved dictator and the Python development team themselves.

In reaction to the flow of protests, Guido has posted the first PEP acceptance
justification, expounding the reasons why this was accepted as the best
solution. The justification shows the kind of thinking that is going into the
PEP process, and despite the disgruntlement of some Python enthusiasts, shows
that the PEP process is working well. This has quieted some of the complaints down. I expect them to taper off this week. While some still feel compelled to argue with the wisdom of accepting PEP 214, it's a done deal. The development team is moving on. When Python 2.0b1 is released in a little over
a week from now, you will be able to print >>myfile, "Hello, my
file!" I am looking forward to this, and I am looking forward to seeing
what controversy will rise up next as this one finally dies down.