2) This wasn't a problem until >> was added, because of problem #2 - the print statement didn't originally let you print to anything other than stdout. Which meant that if you wanted to support writing to a file instead of a stdout then you had to re-implement print yourself.
In practice, I've also found that having print as a function adds functionality because I can do things like:
print(*data_values, sep="\n")
which is a quick way to print each value in a list on its own line.
"Readable" is in the eye of the beholder, which is why I commented that this was something I personally found useful, rather than one of the two subtle flaws I mentioned.
I can also disable all print statements with "def print(* args, * * kwargs): pass" at the top of the module.
I've had times where I couldn't figure out where a print was coming from, so I could replace print() to check the arguments passed in:
import builtins
builtin_print = builtins.print
def my_print(*args, **kwargs):
if "looking for" in args: # adjust as appropriate
1/0
return builtin_print(*args, **kwargs)
builtins.print = my_print
Previously I had to do that by wrapping sys.stdout with my own file-like object, to intercept write(). (Granted, not hard, but harder.)
The fact that you can overwrite built-in functions is not a point in favor of the language. Imagine you do this in a library and everyone using print() in their project would use a modified print instead. You could've just modified sys.stdout instead.
1) it modified the file object's "softspace"
2) This wasn't a problem until >> was added, because of problem #2 - the print statement didn't originally let you print to anything other than stdout. Which meant that if you wanted to support writing to a file instead of a stdout then you had to re-implement print yourself.In practice, I've also found that having print as a function adds functionality because I can do things like:
which is a quick way to print each value in a list on its own line.