Why print statement is not pythonic?
python, python-3.x
Solution
Looks to me like yours is a debate, not a question -- are you really going to accept an answer that shows how deeply and badly wrong you were in your assertions?!
On to your debating points:
There are other operators, such as import which we write as a statement, though their functionality is actually duplicated with a function `__import__`
Absolutely wrong: function `__import__` (like every other function -- and operator, for that matter) binds no names in the scope of "caller" (code containing it) -- any "thingie" that binds names in the "caller's scope" must be a statement (just like assignment, `def`, and `call`). Your "point" appears to totally miss the extremely deep and crucial distinction that Python draws between statements and expressions -- one may reasonably dislike this distinction, but ignoring it is, most obviously, simply wrong.
Python statements are things the Python compiler must be specifically aware of -- they may alter the binding of names, may alter control flow, and/or may need to be entirely removed from the generated bytecode in certain conditions (the latter applies to `assert`). `print` was the only exception to this assertion in Python 2; by removing it from the roster of statements, Python 3 removes an exception, makes the general assertion "just hold", and therefore is a more regular language. Special cases are not special enough to break the rules has long been a Pythonic tenet (do `import this` at an interactive interpreter's `>>>` prompt to see "the Zen of Python" displayed), and this change to the language removes a violation of this tenet that had to remain for many years due to an early, erroneous design decision.
To beginners, the operator print does not belong to the general application logic. To them it's the mysterious operator which is a culmination of their program. They expect it to look differently.
Curing beginners of their misconceptions as early as feasible is a very good thing.
All the beginner books which were describing basic Python 2.x are now guaranteed to be broken from the fist example. Certainly, languages sometimes changes, but changes are usually less visible to novices.
Languages rarely change in deep and backwards-incompatible ways (Python does it about once a decade) and few language features are "highly visible to novices", so the total number of observations is small -- yet even within that tiny compass we can easily find counter-examples, where a feature highly visible to beginners was just so badly designed that removing it was well worth the disruption. For example, modern dialects of Basic, such as Microsoft's Visual Basic, don't use explicit user-entered line numbers, a "feature" that was both terrible and highly visible to absolutely everybody since it was mandatory in early dialects of Basic. Modern variants of Lisp (from Scheme onwards) don't use dynamic scoping, a misfeature that was sadly highly visible (usually manifesting as hard-to-understand bugs in their code) to beginners, basically as soon as they started writing functions in Lisp 1.5 (I once was a beginner in that and can testify to how badly it bit me).
It's not immediately obvious to me that a functionality of print can be duplicated on an application level. For example, sometimes I would like to redirect print from a console as a modal OS dialog.
Not sure I follow this "point". Just change `sys.stdout` to your favorite pseudo-file object and redirect to your heart's contents -- you have the option of monkey patching the built-in function `print` (which you never had in Python 2), but nobody's twisting your arm and forcing you to do so.
While people say it's hard to rewrite all print statements to a function, they have forced every Python 2.x developer to do exactly that for all their projects. Good, it's not hard with automatic converter.
The `2to3` tool does indeed take care of all such easy surface incompatibilities -- no sweat (and it needs to be run anyway to take care of quite a few more besides `print`, so people do use it extensively). So, what's your "point" here?
Everyone who enjoys having an ability to manipulate function print would be just as well-served if print was a statement wrapping function print.
Such an arrangement would not, per se, remove an unnecessary keyword (and most especially, an unjustified irregularity, as I explained above: a statement that has no good reason to be a statement because there is absolutely no need for the compiler to be specially aware of it in any way, shape, or form!). It's far from clear to me that having such an underlying function would add any real value, but if you have real use cases you can certainly propose the case in the Python Ideas mailing list -- such an underlying function, if proven to be precious indeed, could be retrofitted to be used by the `print` statement in Python 2.7 as well as by the `print` function in Python 3.2.
However, consider a typical case in which one might want to monkey-patch the built-in `print`: adding keyword arguments to allow fancy tweaks. How would the `__print__` function you're apparently proposed ever ge those KW arguments from a `__print__` statement? Some funkier syntax yet than the horrors of `>> myfile` and the trailing comma...?! With `print` as a function, keyword arguments follow just the perfectly normal and ordinary rules that apply to every function and function call -- bliss!
So, in summary, it's more Pythonic for `print` to be a function because it removes anomalies, special cases, and any need for weird exceptional syntax -- simplicity, regularity, and uniformity are Python's trademark.
Problem
This question was bugging me for quite a while (as evidenced by my previous question): why exactly is `print(x)` better (which is defined as being more pythonic) than `print x`? For those who don't know, the `print` statement was changed into function in Python 3.0. The formal documentation is in PEP 3105 and motivation is in Guido van Rossum's email. To those points I would like to make a counterpoint: - There are other operators, such as `import` which we write as a statement, though their functionality is actually duplicated with a function `__import__` - To beginners, the operator `print` does not belong to the general application logic. To them it's the mysterious operator which is a culmination of their program. They expect it to look differently. - All the beginner books which were describing basic Python 2.x are now guaranteed to be broken from the first example. Certainly, languages sometimes change, but those changes are usually less visible to novices. - It's not immediately obvious to me that a functionality of `print` can be duplicated on an application level. For example, sometimes I would like to redirect print from a console as a modal OS dialog. - While people say it's hard to rewrite all `print` statements to a function, they have forced every Python 2.x developer to do exactly that for all their projects. Good, it's not hard with automatic converter. - Everyone who enjoys having an ability to manipulate function `print` would be just as well-served if `print` was a statement wrapping function `__print__`. So, can we please have a canonical answer to this question on the pages of Stack Overflow?