I\'ve heard several times that print being a function (3.x) is better than it being a statement (2.x). But why?
I was a fan of it being a statement mainly because it
Everything from Jochen's answer and Sven's answer, plus:
You can use print()
it in places where you can't use print
, such as:
[print(x) for x in range(10)]
You can replace the built-in print
by a custom one:
import os
import sys
def print(s):
sys.stderr.write('Will now print ' + str(s) + '.' + os.linesep)
sys.stdout.write(str(s) + os.linesep)
print(['A', 'list'])
# Output:
# stderr: Will now print ['A', 'list'].
# stdout: ['A', 'list']
You can use print
inside a lambda or a function call etc.:
example_timeout_function(call=lambda: print('Hello world'), timeout=5)
do_things(print_function=print)
Rationale
The print statement has long appeared on lists of dubious language features that are to be removed in Python 3000, such as Guido's "Python Regrets" presentation [1]. As such, the objective of this PEP is not new, though it might become much disputed among Python developers.
The following arguments for a print() function are distilled from a python-3000 message by Guido himself [2]:
- 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.
- At some point in application development one quite often feels the need to replace print output by something more sophisticated, like logging calls or calls into some other I/O library. With a print() function, this is a straightforward string replacement, today it is a mess adding all those parentheses and possibly converting >>stream style syntax.
- Having special syntax for print puts up a much larger barrier for evolution, e.g. a hypothetical new printf() function is not too far fetched when it will coexist with a print() function.
- There's no easy way to convert print statements into another call if one needs a different separator, not spaces, or none at all. Also, there's no easy way at all to conveniently print objects with some other separator than a space.
- If print() is 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, one 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.— PEP 3105 – Make print a function
I thought over this question and had no idea about pros of python 3 version. But when I needed to print the columns of pandas.DataFrame
(without Index([...])
), I've found out that
print *df.columns
throws an exception, while
print(*df.columns)
works fine! And if you want to have same (configurable) print options in several call prints, you can save them to dictionary and pass as **print_options
So at least *args
, **kw_args
tricks are a good reason for print
to be a function!
One advantage of print
being a function is consistency. There is no reason for it to be a statement. Compare these two lines
2.x: print >> my_file, x
3.x: print(x, file=my_file)
The new version looks much more like Python, doesn't it?
Another advantage of the function version is flexibility. For example, if you want to catch all print
calls for debugging purposes, you can now simply redefine print
:
def print(*args, **kwargs):
# whatever
__builtins__.print(*args, **kwargs)