StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>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?!</p> <p>On to your debating points:</p> <blockquote> <p>There are other operators, such as import which we write as a statement, though their functionality is actually duplicated with a function <code>__import__</code></p> </blockquote> <p>Absolutely wrong: function <code>__import__</code> (like <strong>every</strong> other function -- and operator, for that matter) binds <strong>no</strong> names in the scope of "caller" (code containing it) -- any "thingie" that binds names in the "caller's scope" <strong>must</strong> be a statement (just like assignment, <code>def</code>, and <code>call</code>). Your "point" appears to totally miss the extremely deep and crucial distinction that Python draws between statements and expressions -- one may reasonably <em>dislike</em> this distinction, but <em>ignoring</em> it is, most obviously, simply wrong.</p> <p>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 <code>assert</code>). <code>print</code> was the <strong>only</strong> 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. <strong>Special cases are not special enough to break the rules</strong> has long been a Pythonic tenet (do <code>import this</code> at an interactive interpreter's <code>>>></code> 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.</p> <blockquote> <p>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.</p> </blockquote> <p>Curing beginners of their misconceptions as early as feasible is a very good thing.</p> <blockquote> <p>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.</p> </blockquote> <p>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). </p> <blockquote> <p>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.</p> </blockquote> <p>Not sure I follow this "point". Just change <code>sys.stdout</code> to your favorite pseudo-file object and redirect to your heart's contents -- you have the <em>option</em> of monkey patching the built-in function <code>print</code> (which you never had in Python 2), but nobody's twisting your arm and forcing you to do so.</p> <blockquote> <p>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.</p> </blockquote> <p>The <code>2to3</code> 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 <code>print</code>, so people do use it extensively). So, what's your "point" here?</p> <blockquote> <p>Everyone who enjoys having an ability to manipulate function print would be just as well-served if print was a statement wrapping function <strong>print</strong>.</p> </blockquote> <p>Such an arrangement would not, per se, remove an unnecessary keyword (and most especially, an unjustified <strong>irregularity</strong>, as I explained above: a statement that has <strong>no</strong> good reason to <strong>be</strong> 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 <code>print</code> statement in Python 2.7 as well as by the <code>print</code> function in Python 3.2.</p> <p>However, consider a typical case in which one might want to monkey-patch the built-in <code>print</code>: adding keyword arguments to allow fancy tweaks. How would the <code>__print__</code> function you're apparently proposed ever ge those KW arguments from a <code>__print__</code> statement? Some funkier syntax yet than the horrors of <code>>> myfile</code> and the trailing comma...?! With <code>print</code> as a function, keyword arguments follow just the perfectly normal and ordinary rules that apply to <strong>every</strong> function and function call -- bliss!</p> <p>So, in summary, it's more Pythonic for <code>print</code> 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.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload