Python DevCenter
oreilly.comSafari Books Online.Conferences.


Python News

Print Changes Survive Criticism


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.

Stephen Figgins administrates Linux servers for Sunflower Broadband, a cable company.

Read more Python News columns.

Discuss this article in the O'Reilly Network Python Forum.

Return to the Python DevCenter.


Sponsored by: