Added the essence of my post to c.l.py in defense of the new syntax.

pep-0214.txt

@@ -140,6 +140,118 @@ Alternative Approaches
     in between each item.
 
 
+More Justification by the BDFL
+
+    The proposal has been challenged on the newsgroup.  One series of
+    challenges doesn't like '>>' and would rather see some other
+    symbol.
+
+    Challenge: Why not one of these?
+
+        print in stderr items,.... 
+        print + stderr items,.......
+        print[stderr] items,.....
+        print to stderr items,.....
+
+    Response: If we want to use a special symbol (print <symbol>
+    expression), the Python parser requires that it is not already a
+    symbol that can start an expression -- otherwise it can't decide
+    which form of print statement is used.  (The Python parser is a
+    simple LL(1) or recursive descent parser.)
+
+    This means that we can't use the "keyword only in context trick"
+    that was used for "import as", because an identifier can start an
+    expression.  This rules out +stderr, [sterr], and to stderr.  It
+    leaves us with binary operator symbols and other miscellaneous
+    symbols that are currently illegal here, such as 'import'.
+
+    If I had to choose between 'print in file' and 'print >> file' I
+    would definitely choose '>>'.  In part because 'in' would be a new
+    invention (I know of no other language that uses it, while '>>' is
+    used in sh, awk, Perl, and C++), in part because '>>', being
+    non-alphabetic, stands out more so is more likely to catch the
+    reader's attention.
+
+    Challenge: Why does there have to be a comma between the file and
+    the rest?
+
+    Response: The comma separating the file from the following expression is
+    necessary!  Of course you want the file to be an arbitrary
+    expression, not just a single word.  (You definitely want to be
+    able to write print >>sys.stderr.)  Without the expression the
+    parser would't be able to distinguish where that expression ends
+    and where the next one begins, e.g.
+
+        print >>i +1, 2
+        print >>a [1], 2
+        print >>f (1), 2
+
+    Challenge: Why do you need a syntax extension?  Why not
+    writeln(file, item, ...)?
+
+    Response: First of all, this is lacking a feature of the print
+    statement: the trailing comma to print which suppresses the final
+    newline.  Note that 'print a,' still isn't equivalent to
+    'sys.stdout.write(a)' -- print inserts a space between items, and
+    takes arbitrary objects as arguments; write() doesn't insert a
+    space and requires a single string.
+
+    When you are considering an extension for the print statement,
+    it's not right to add a function or method that adds a new feature
+    in one dimension (where the output goes) but takes away in another
+    dimension (spaces between items, and the choice of trailing
+    newline or not).  We could add a whole slew of methods or
+    functions to deal with the various cases but that seems to add
+    more confusion than necessary, and would only make sense if we
+    were to deprecate the print statement altogether.
+
+    I feel that this debate is really about whether print should have
+    been a function or method rather than a statement.  If you are in
+    the function camp, of course adding special syntax to the existing
+    print statement is not something you like.  I suspect the
+    objection to the new syntax comes mostly from people who already
+    think that the print statement was a bad idea.  Am I right?
+
+    About 10 years ago I debated with myself whether to make the most
+    basic from of output a function or a statement; basically I was
+    trying to decide between "print(item, ...)" and "print item, ...".
+    I chose to make it a statement because printing needs to be taught
+    very early on, and is very important in the programs that
+    beginners write.  Also, because ABC, which lead the way for so
+    many things, made it a statement.  In a move that's typical for
+    the interaction between ABC and Python, I changed the name from
+    WRITE to print, and reversed the convention for adding newlines
+    from requiring extra syntax to add a newline (ABC used trailing
+    slashes to indicate newlines) to requiring extra syntax (the
+    trailing comma) to suppress the newline.  I kept the feature that
+    items are separated by whitespace on output.
+
+    Full example: in ABC,
+
+        WRITE 1
+        WRITE 2/
+
+    has the same effect as
+
+        print 1,
+        print 2
+
+    has in Python, outputting in effect "1 2\n".
+
+    I'm not 100% sure that the choice for a statement was right (ABC
+    had the compelling reason that it used statement syntax for
+    anything with side effects, but Python doesn't have this
+    convention), but I'm also not convinced that it's wrong.  I
+    certainly like the economy of the print statement.  (I'm a rabid
+    Lisp-hater -- syntax-wise, not semantics-wise! -- and excessive
+    parentheses in syntax annoy me.  Don't ever write return(i) or
+    if(x==y): in your Python code! :-)
+
+    Anyway, I'm not ready to deprecate the print statement, and over
+    the years we've had many requests for an option to specify the
+    file.
+
+
 References
 
     [1] http://www.python.org/doc/current/ref/print.html