== Python 3's _print()_ annoys me (although maybe it shouldn't)

One of a number of changes in Python 3 that I have a visceral unhappy
reaction to is the replacement of the _print_ statement by the _print()_
function. On the one hand I sort of understand the 'computer science'
perspective on changing it to a function; it moves Python's explicit
statements closer to being purely intrinsic language operators. On the
other hand, I just don't like it.

I think that part of the reason I don't like it is that it remains more
or less magic while hiding that magic. When _print_ was a statement,
it was clear that it was pretty unusual and special. Turning _print()_
into a function does not really make it any less magical (or central),
but it sort of pretends otherwise in my eyes; the magic is now hidden
behind a function call. Part of this feeling probably comes because
_print()_ is a built-in function, which makes it specially privileged;
I'd consider _sys.print()_ to be less magical (although more stupid;
printing things is a pretty common and important operation, so short
names for it matter).

On a pragmatic level, though, I'm clearly wrong; Python 3 _print()_
is significantly less magical than Python 2 _print_, at least in
CPython. CPython 2 has special bytecodes for printing things and
_print_ compiles down to them, while in Python 3 uses of _print()_
compile to ordinary (global) function calls (and you can even redefine
_print()_ yourself if you want to be perverse). The arguments and
special behaviors are also more regular and more easily discoverable (as
a function, _print()_ has in-Python documentation that you can see with
_help()_).

(That _print()_ is a real function opens up heavy use of _print()_
to various sorts of the usual optimizations, and means that it's
intrinsically somewhat slower than the Python 2 version since it
necessarily involves a function name lookup and a function call. It's
unlikely that this will matter to any real code, but you never know.)

PS: I know, I know. Even Python 2 has plenty of magical functions in the
global namespace, things like _type()_ or _str()_. I don't claim that my
annoyance at _print()_ is rational and I probably wouldn't be annoyed if
Python had always had a _print()_ function. Which implies that part of
my annoyance may be due to what I see as a basically pointless renaming
of a builtin to a function, one that forces a whole bunch of noisy code
changes for no really compelling reason. (There is an entire rant about
language changes without strong reasons that could go here.)

Also, I just tend to think that _print_ reads better because it stands
out more than yet another function call.

=== Sidebar: why C's _printf()_ doesn't irritate me similarly

The simple version is that _printf()_ is clearly a library function.
A large part of the reason that this works in C and doesn't work
in Python is namespaces, in that Python has them and C doesn't. In C
everyone can dump functions into what in Python is the global namespace;
in Python, modules cannot do this, which makes builtin names like
_print()_ special. Another reason this works in C is that producing
output is clearly out of scope of the core C language, which is very
limited and confined (it doesn't even have dynamic memory allocation).