<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 19 April 2016 at 14:52, Franklin? Lee <span dir="ltr"><<a href="mailto:leewangzhong+python@gmail.com" target="_blank">leewangzhong+python@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Apr 18, 2016 at 11:51 AM, Ethan Furman <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br></span><span class="">
> Or even Nick's (that you snipped):<br>
>><br>
</span><span class="">>> Since the more the REPL does, the more opportunities there are for<br>
><br>
>> it to break when debugging, having the output hooks be as simple as<br>
>> possible is quite desirable.<br>
<br>
</span>I read this as, "It'll be more complicated, so it MIGHT be buggy."<br>
This seems solvable via design, and doesn't speak to whether it's<br>
good, in principle, to limit output per input. If you still think it's<br>
a good reason, then I probably didn't understand it correctly.<br></blockquote><br></div><div class="gmail_quote">No, that's not what it means. It relates to one of the ways experienced developers are able to debug code: by running it in their heads, and comparing the result their brain computed with what actually happened. When there's a discrepancy, either their expectation is wrong or the code is wrong, and they need to investigate further to figure out which it is. When folks say "Python fits my brain" this is often what they're talking about.<br><br></div><div class="gmail_quote">Implicit side effects from hidden code break that mental equivalence - it's why effective uses of metaclasses, monkeypatching, and other techniques for deliberately introducing changed implicit behaviour often also involve introducing some kind of more local signal to help convey what is going on (such as a naming convention, or ensuring the altered behaviour is used consistently across the entire project).<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The default REPL behaviour is appropriate for this "somewhat experienced Pythonista tinkering with code to see how it behaves" use case - keeping the results very close to what they would be if you typed the same line of code into a text file and ran it that way. It's not necessarily the best way to *learn* those equivalences, but that's also not what it's designed for.<br><br></div><div class="gmail_quote">IPython's REPL is tailored for a different audience - their primary audience is research scientists, and they want to be able to better eyeball calculation results, rather than lower level Python instance representations. As a result, it's much cleverer than the default REPL, but it's also aiming to tap into people's intuitions about the shape of their data and the expected outcomes of the operations they're performing on it, rather than their ability to mentally run Python code specifically.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">A REPL designed specifically for folks learning Python, like the one in the Mu editor, or the direction IDLE seems to be going, would likely be better off choosing different default settings for sys displayhook and sys.excepthook, but those changes would be best selected based on direct observations of classrooms and workshops, and noting where folks get confused or intimidated by the default settings. For environments other than IDLE, they can also be iterated on at a much higher rate than we make CPython releases.<br></div><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>