On Tue, Nov 12, 2013 at 11:45 AM, anatoly techtonik
On Tue, Nov 12, 2013 at 10:30 AM, Steven D'Aprano
wrote: On Tue, Nov 12, 2013 at 07:44:03PM +1300, Greg Ewing wrote:
Xuancong Wang wrote:
As you know, reading from and writing to IO is a high frequency operation.
Actually, no, I don't know that. Thinking about the code I write, the proportion of it devoted to textual output is probably less than 1%, often far less. So by your argument it should have a rather verbose encoding!
I agree strongly! print is simply not important enough to dedicated compiler magic to have it behave differently from every other function. ... Although practicality beats purity. ...
I bet that most people here started with Python at time when UX as a definition was unknown, but things that resulted in good UX were called 'pythonic'. http://www.youtube.com/watch?v=Ovj4hFxko7c
Now about strong agreement from Steven. I believe this agreement is strictly theoretical. You know - "In theory, practice and theory are the same, but in practice..." - of this type. If we leave the discussion of "dedicated compiler magic" and "proper editor" aside and discuss only the User eXperience - don't you think that fast-typing "print var" is more convenient than "print(var)"?
I believe that nobody objects against a better UX, but Steven pinpointed the conflicting point, which I'd like to stress - "dedicated compiler magic". I dislike enforced () in Py3k print as much as two other authors who raised questions about it here in the past week, but I kind of accept it existence for two reasons:
1. it is a clear mark of Python 3 compatible code 2. it makes Python interpreter interpret code faster [1], more reliable [1], less resource consuming [1] on low level platforms, such as Raspberry PI
[1]: reference needed - I haven't seen any proof, except maybe a picture of difference in a parse tree (which probably got simplified, because print is now a function, and more complicated, because yield is not)
s/yield is/yield, yield from are/
Solution. My position is that I'd like to have both: 1. simple "print<SPACE>something" statement as a development aid for quick troubleshooting/debugging/hacking/writing (which may map to a function with single argument call) 2. print() function, for overriding, sending to other functions as param etc.
I just picked one random project of mine, and found 23 instances of print in 1644 lines of code, or just under 1.4% of lines. In another project, I had zero instances of print in 2149 lines. In another project, I had 11 instances of the string print, but only 1 was the print statement (the rest were in documentation), out of 791 lines, approximately 0.1%.
When researching programs, 90% of code I type are prints, which are never committed anywhere. When developing, I believe it is about 30%, because it is several orders faster to check that all inputs/outputs work correctly than to write proper test suite.
So, your metrics is mostly relevant for the primary "print typing" use case that I personally find very annoying if applied to Python 3.
s/relevant/irrelevant/
Consistency is far more important than saving a few key strokes. If print magically treats parentheses as optional, so that these are the same:
print a, b, c, sep="**" print(a, b, c, sep="**")
people will be confused why print is so special and they can't do the same with any arbitrary function:
result = 1 + my_function a, b, c, keyword_argument=42
The first case is "print as statement". The second is "print as expression".
People won't be confused, because 'result = print a,b,a' syntax is incorrect in the scenario I proposed.
And of course, there is the problem that leaving out the parentheses makes it ambiguous in Python 3. Does this:
my_tuple = (100, 200, print 42, "hello")
print "42" and generate the tuple (100, 200, None, "hello"), or does it print "42 hello" and generate the tuple (100, 200, None)?
Will it be good if only 'my_tuple = (100, 200, print(42), "hello")' syntax is supported in expression?