Operator precedence isn't really a new concept, and Python relies on it in plenty other situations:

    bar = 1 + 1

I do believe Python made the right call, actually: print needed to be unified with functions, and dropping the requirement for parenthesis for function calls would have introduced so much incompatibility as to make the Python 2 -> 3 transition far more difficult.

But ignoring the legacy issue, there is a better way to do function calls, and it is ruby.

What does operator precedence have to do with this? Ending a parameter list with a comma changes the output of the print keyword but not a function. Assignment statements can contain function calls but not the print keyword.

C style function calls are common, explicit, and consistent. Python adds the best combination of positional, variadic, and named parameters of any language I know. ML style has less punctuation and simpler grouping rules. Ruby has the weaknesses of both.

Haskell/ml/caml do it better than Ruby.

    f 1 2
    (f 1 2).thing

Here the parentheses are nothing special, they just hint precedence.

As opposed to

    f 1, 2
    f(1, 2).thing

Awkward special-case commas and parentheses.

Didn't Ruby borrow it from Perl?

And lisp, just less parentheses

That usage doesn't get the weirdly specific error message though. It's only the Python2-ish statement that gets one.

What does someone want "print foo" to do if "print" is a different function?

What does someone want "print (1, 2)" to do if "print" is the built-in function? It prints a tuple in Python 2 and ints in Python 3.

I get that. So the Python 3 interpreter has to assume that when I say "print (1, 2)", I actually mean, print these two individual arguments.

If I say "print 'foo'" though, it recommends "print ('foo')", but doesn't go all the way to assume I actually meant that. There's a piece of code handling that special case that stops short of actually interpreting what I apparently mean.

The frustration around that was the original point.