4 ms·

You mention print in lambda, and it's also in the article. I don't think that's good enough reason for killing the usability of print statement in repl. I'd co

by t0mk 11y ago

You mention print in lambda, and it's also in the article. I don't think that's good enough reason for killing the usability of print statement in repl. I'd consider it quite a weird piece of code if I'd see print in lambda, or passed to something from functools. If "sys.stdout.write" would be there instead of the "print", I'd see it equally weird. Both is (probably unnecessary) giving away the simplicity of Python. I debug in REPL quite a lot and I don't do functional magic with print at all (at the moment). That's dragging me away from Python 3. Other people might have it different.

wickawic 11y ago
It seems silly that typing a single extra character at the end of the line (noting that the left parenthesis was previously a space) is "dragging you away from python". It is also worth noting that the IPython repl will close parentheses for you, so you actually don't have to type any more characters at all!
ubertaco 11y ago
>I don't think that's good enough reason for killing the usability of print statement in repl. I really don't think the difference between print(some_var) and print some_var constitutes "killing usability". > I'd consider it quite a weird piece of code if I'd see print in lambda Granted, I don't do much Python these days (I have become enamored with more strongly-typed langs lately), but my impression is that lambdas are uncommon in python, instead preferring relatively-inexpensive toplevel function defs instead. > I debug in REPL quite a lot and I don't do functional magic with print at all (at the moment) Consider a case where I'm debugging why my function foo(x) is failing for at least one of [42, 333, -57, 0, None, 33], but I don't know which one. It's not unheard of to do some step-by-step binary-search stuff like this: >> [print(foo(x)) for x in test_cases[0:3]] # repl doesn't blow up >> [print(foo(x)) for x in test_cases[3:]] # repl blows up as expected >> [print(foo(x)) for x in test_cases[4:]] # repl doesn't blow up, so now I know that foo(0) has a bug Now, you might look at this and point out that I don't actually need to print(foo(x)) at all, that the REPL will display the resulting arrays anyways. And you're right! So even here, the difference between "print(x)" and "print x" doesn't "kill usability", since it's a moot point either way. I think in day-to-day use, even at a REPL, it's a "six of one, half-dozen of another" scenario with no major wins either way. In teaching Python, it's a win because it's more consistent -- you don't have to teach people "this is how it looks to call a function -- except print, it's not really a real function, it's special, so make sure you remember this one exception." And in building Python, it means one fewer special case to maintain for the interpreter and language.

by t0mk 11y ago

wickawic 11y ago

It seems silly that typing a single extra character at the end of the line (noting that the left parenthesis was previously a space) is "dragging you away from python". It is also worth noting that the IPython repl will close parentheses for you, so you actually don't have to type any more characters at all!

ubertaco 11y ago

>I don't think that's good enough reason for killing the usability of print statement in repl. I really don't think the difference between print(some_var) and print some_var constitutes "killing usability". > I'd consider it quite a weird piece of code if I'd see print in lambda Granted, I don't do much Python these days (I have become enamored with more strongly-typed langs lately), but my impression is that lambdas are uncommon in python, instead preferring relatively-inexpensive toplevel function defs instead. > I debug in REPL quite a lot and I don't do functional magic with print at all (at the moment) Consider a case where I'm debugging why my function foo(x) is failing for at least one of [42, 333, -57, 0, None, 33], but I don't know which one. It's not unheard of to do some step-by-step binary-search stuff like this: >> [print(foo(x)) for x in test_cases[0:3]] # repl doesn't blow up >> [print(foo(x)) for x in test_cases[3:]] # repl blows up as expected >> [print(foo(x)) for x in test_cases[4:]] # repl doesn't blow up, so now I know that foo(0) has a bug Now, you might look at this and point out that I don't actually need to print(foo(x)) at all, that the REPL will display the resulting arrays anyways. And you're right! So even here, the difference between "print(x)" and "print x" doesn't "kill usability", since it's a moot point either way. I think in day-to-day use, even at a REPL, it's a "six of one, half-dozen of another" scenario with no major wins either way. In teaching Python, it's a win because it's more consistent -- you don't have to teach people "this is how it looks to call a function -- except print, it's not really a real function, it's special, so make sure you remember this one exception." And in building Python, it means one fewer special case to maintain for the interpreter and language.