Old Man Yells At Cloud

[Steve D'Aprano]

On Sun, 17 Sep 2017 11:51 pm, Tim Golden wrote:

> Print-as-a-function removed one small simplicity 

Presumably you've never wanted to print to something other than std.out. The
syntax in Python 2 is horrid:

print >>sys.stderr, args

Presumably you've never wanted to print using a separator other than space. You
simply can't do it at all in Python 2.

Presumably you've never wanted to print and suppress the newline at the end of
the line. The Python 2 syntax is obscure, error-prone, and easy to miss:

print a, b, c, d,  # WOT?

Presumably you've never wanted to pass print to something as a function. It
can't be done in Python 2:

something.register(callback=print)  # SyntaxError

Presumably you've never wanted to control when the output buffer is flushed.
That's another thing you can't do in Python 2.

Presumably you've never wanted to monkey-patch an existing function that used
print by shadowing the built-in. You can't do that in Python 2, since print
isn't a regular name, it can't be mocked or shadowed or replaced.

I've wanted to do all those things, and more. I love the new print function. For
the cost of one extra character, the closing bracket, it gives you much, much
more than the old print statement ever did.

print(value, ..., sep=' ', end='\n', file=sys.stdout, flush=False)

No more cryptic and ugly syntax for printing to a file. Setting the argument
separator is easy. Instead of an obscure and easy to miss trick to suppress the
end of line, you use an obvious and self-explanatory keyword argument. The
function is easy to extend in the future with extra keyword arguments. It is
trivial to pass around, like any other function, and easy to mock or shadow.

The print statement was only good for the most simple uses. The print function
is a powerful, useful and first-class component of your programming toolbox.

[...]
> Funnily enough, the two arguments most often advanced for
> print-as-function seem to me to cancel each other out.

Arguments by whom?

There's a whole raft of things wrong with print as a statement. Arguably, none
of them *alone* are sufficient to condemn it, but overall, it makes the print
statement substandard. 


> Argument 1 is 
> "this way you can redefine print to be, eg, write_to_this_log"; and 
> Argument 2 is "but no-one uses print in real code anyway" -- more or
> less what Mark offered just now.

That second one is neither an argument in favour of changing print, nor correct.
People do use print in real code, but even if they didn't, that's not in and of
itself a reason to change print.


> Well if no-one uses it in real code, then its ability to be redefined is
> moot. (Or, rather, the strength of that argument is diminished).
> 
> In my own code I'm obviously quite capable of defining a function p()
> which does whatever I want in terms of printing etc.

Sure you can. But where the ability to mock print shines is when you're dealing
with an already existing function that you cannot change and that already uses
print.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.