[Python-Dev] Replacement for print in Python 3.0

[Guido van Rossum]

On 9/3/05, Bill Janssen <janssen at parc.com> wrote:
> So here's the summary of the arguments against: two style points
> (trailing comma and >>stream) (from the man who approved the current
> decorator syntax!), and it's hard to extend.  (By the way, I agree that
> the ">>" syntax is ugly, and IMO a bad idea in general.  Shame the "@"
> wasn't used instead. :-)
> 
> Seems pretty weak to me.  Are there other args against?

Sure. I made the mistake of thinking that everybody knew them. But let
me first summarize the arguments I've heard for keeping print as a
statement:

1. It's always been there
2. We don't want to type parentheses
3. We use it a lot
4. We don't want to change our code

I agree that those are strong arguments, so please hear me out.

There is a theoretical argument: print is the only application-level
functionality that has a statement dedicated to it. Within Python's
world, syntax is generally used as a last resort, when something
*can't* be done without help from the compiler. Print doesn't qualify
for such an exception (quite the opposite actually).

But more important to me are my own experiences exploring the
boundaries of print.

- I quite often come to a point in the evolution of a program where I
need to change all print statements into logging calls, or calls into
some other I/O or UI library. If print were a function, this would be
a straightforward string replacement; as it is, finding where to add
the parentheses is often a pain (the end isn't always on the same line
as the start). It's even worse if there are already ">>stream" options
present. Trailing commas also make this more complicated than it needs
to be.

- Having special syntax puts up a much larger barrier for evolution of
a feature. For examle, adding printf (or changing print to printf) is
a much bigger deal now that print is a statement than if it had been a
built-in function: trial implementations are much more work, there are
only a few people who know how to modify Python's bytecode compiler,
etc. (Having printf() be a function and print remain a statement is of
course a possibility, but only adds more confusion and makes printf()
a second-class citizen, thereby proving my point.)

- There is a distinct non-linearity in print's ease of use once you
decide that you don't want to have spaces between items; you either
have to switch to using sys.stdout.write(), or you have to collect all
items in a string. This is not a simple transformation, consider what
it takes to get rid of the spaces before the commas in this simple
example:

    print "x =", x, ", y =", y, ", z =", z

If it was a built-in function, having a built-in companion function
that did a similar thing without inserting spaces and adding a newline
would be the logical thing to do (or adding keyword parameters to
control that behavior; but I prefer a second function); but with only
print as it currently stands, you'd have to switch to something like

    print "x = " + str(x) + ", y = " + str(x) + ", z = " + str(z)

or

    print "x = %s, y = %s, z = %s" % (x, y, z)

neither of which is very attractive. (And don't tell me that the
spaces are no big deal -- they aren't in *this* example, but they are
in other situations.)

- If it were a function, it would be much easier to replace it within
one module (just def print(*args):...) or even throughout a program
(e.g. by putting a different function in __builtin__.print). As it is,
you can do this by writing a class with a write( ) method and
assigning that to sys.stdout -- that's not bad, but definitely a much
larger conceptual leap, and it works at a different level than print.

Summarizing, my main problems with print as a statement are the
transformations -- when print doesn't cut it, you have to switch to
something entirely different. If it were a function the switch would
feel much smoother. I find that important: things that are
conceptually related should be syntactically related (within the realm
of common sense, as always).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)