The (non-)return of the Python print statement

In what may have seemed like an April Fool's Day joke to some, Python creator Guido van Rossum recently floated the idea of bringing back the print statement—several months after Python 2, which had such a statement, reached its end of life. In fact, Van Rossum acknowledged that readers of his message to the python-ideas mailing list might be checking the date: "No, it's not April 1st." He was serious about the idea—at least if others were interested in having the feature—but he withdrew it fairly quickly when it became clear that there were few takers. The main reason he brought it up is interesting, though: the new parser for CPython makes it easy to bring back print from Python 2 (and before).

Prior to Python 3, the print statement was the usual way to print output to the screen:

    >>> print '1 + 2 = ', 1+2
    1 + 2 = 3

    from __future__ import print_function

The new parser is based on a parsing expression grammar (PEG) and it was a fairly simple matter to make the change: "One thing that the PEG parser makes possible in about 20 lines of code is something not entirely different from the old print statement." He has a prototype working, but it enables far more than just print statements:

>>> len "abc"
3

>>> import sys
>>> sys.getrefcount "abc"
24

>>> class C:
...   def foo(self, arg): print arg
... 
>>> C().foo 2+2
4

He noted that there are some downsides too, including a "bare" print statement being interpreted as the print() function and not a call to it. Potentially more problematic is the behavior when the first argument to the print statement uses parentheses.

>>> print (1, 2, 3)
1 2 3

>>> print (2+2), 42
4
(None, 42)

Currently a bunch of effort is made in the parser to recognize code that is trying to use the print statement, so that it results in a SyntaxError that suggests adding parentheses ("Did you mean print('hello world')"). That code could be removed if print was resurrected. Van Rossum said that it was not an "all or nothing" proposal, it could be dialed back somewhat by restricting what kinds of function calls it would work for or restricting it only to "print". He also noted that he would withdraw the idea "if the response is a resounding 'boo, hiss'".

It may not have been resounding, but the response was definitely mostly of the "boo, hiss" variety (including some that used that phrase directly, of course). Ethan Furman said that while too many parentheses made code hard to read for him, too few is also problematic, so he was not in favor of any change. Naomi Ceder had mixed feelings; she has struggled to switch to the print() function over the last five years (after 15 years of print without parentheses). "As someone who teaches Python and groans at explaining exceptions, I'm -0 on print without parens and -1 on other calls without parens."

Gregory P. Smith agreed with Ceder, but took it further ("-1 overall for me..."), even though Smith liked the print statement for Python 2 and earlier. Beyond just print, though, he is concerned that calling functions without requiring parentheses will just lead to "a whole new world of typos and misunderstandings". Other languages allow that kind of thing, but Python is not those languages. "I love that the new parser allows us to even explore these possibilities. We should be very cautious about what syntax changes we actually adopt."

Overall, Smith's sentiment seemed popular; there were some who viewed parts of the idea favorably, but the full-blown proposal, including making any kind of call without parentheses, was not well-liked. For his part, Van Rossum said there was an element of "because we can" to the idea; he was pleasantly surprised at how easy it was to make it work with the new parser. He described why the PEG parser made things so much easier in his initial message:

But Van Rossum said that he would "happily withdraw" the idea since it did not seem to be gaining any real traction. It seems likely that the idea came out of the blue for many—there were multiple good reasons to switch to a print() function as part of the Python 3 transition, after all. But the proposal does serve another purpose: it allows the CPython core developers to see the scope of the types of changes the PEG parser is bringing to the table. That may well open up some interesting features moving forward.