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

[anatoly techtonik]

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)



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.

> 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?
--
anatoly t.