The print function was one of the worst offenders. It is a pointless vanity feature (Guido prefers the new syntax), hardly worth the economic cost of upgrading all Python code in existence to adopt it.
https://www.python.org/dev/peps/pep-0214/
Where he basically said "Maybe print should be a function, but... nah".
Two years later, he says he regrets it:
http://legacy.python.org/doc/essays/ppt/regrets/PythonRegret...
And the benefits are explained here:
(Sorry, trolling. ML-style function call syntax would clash a lot with other parts of Python.)
def g(): return 5
assert g() == 5
assert g != 5
Look here: http://try.ocamlpro.com/
Try this code:
let g() = 5 g() == 5 g != 5
First line defines the function. Second line should evaluate to true. Third line doesn't type check because a function is not the same type as a literal.
Haskell does differentiate between IO-actions and functions. Here is an example:
main = do
let printFive = print 5
print 1
printFive
print 6
printFive
1
5
6
5
How? How do I compare. say, two functions for equality, without comparing the return value instead?
The decoupling of function calling and IO actions can work in non-statically typed languages, too.
Your question concerns a different topic. To give something like an answer: that problem can only occur with `functions' of zero arguments. Haskell sidesteps the issue by requiring all functions to have exactly one argument.
Second of all it's such a silly syntactic difference that if people are honestly bothered enough by it to stay on python 2 i just lost all hope for that community. Besides, the reason for changing it was not vanity with syntax, it was to move it from a language keyword into a standard function so it could be used in all the ways described above, marvys links describe this better.
Since pretty much everything has at least one print statement, its removal ensured that everything had to be converted.
If Guido&co had tried to maintain backwards compatibility, they could have more easily made the important semantic changes (like unicode strings). Users would have been enthusiastic to upgrade, instead of angry that their time and money was being wasted on irrelevant syntax details.
People know that global variables are a bad thing but fail to realize that print "foo" is essentially equivalent to global_variable_output_buffer+="foo". It simply shouldn't be scattered around everywhere.
This is not just academic nonsense, I was once given the task to parallelize the code in a large python code base, and to send the output in an email instead of printing to console. It would have been an easy job but a lot of the code was using print just the way you describe it causing intermingled output in the console when run in parallel.