diff --git a/pep-0214.txt b/pep-0214.txt index 820629a51..97d4bf4b1 100644 --- a/pep-0214.txt +++ b/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 + 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