[Python-checkins] peps: Added the essence of my post to c.l.py in defense of the new syntax.
georg.brandl
python-checkins at python.org
Wed Mar 23 21:27:25 CET 2011
http://hg.python.org/peps/rev/b8297f714e15
changeset: 162:b8297f714e15
user: Guido van Rossum <guido at python.org>
date: Fri Aug 25 14:15:49 2000 +0000
summary:
Added the essence of my post to c.l.py in defense of the new syntax.
files:
pep-0214.txt | 112 +++++++++++++++++++++++++++++++++++++++
1 files changed, 112 insertions(+), 0 deletions(-)
diff --git a/pep-0214.txt b/pep-0214.txt
--- a/pep-0214.txt
+++ b/pep-0214.txt
@@ -140,6 +140,118 @@
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
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list