[Python-ideas] A suggestion for Python 3 vs Python 2

[anatoly techtonik]

On Tue, Nov 12, 2013 at 11:45 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> On Tue, Nov 12, 2013 at 10:30 AM, Steven D'Aprano <steve at pearwood.info> 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?