[Python-ideas] Have REPL print less by default

[Terry Reedy]

On 4/19/2016 11:18 PM, Dan Sommers wrote:
> On Wed, 20 Apr 2016 02:18:58 +1000, Steven D'Aprano wrote:
>
>> On Tue, Apr 19, 2016 at 11:12:16PM +1000, Nick Coghlan wrote:
>
>>> 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.
>
> That's a pretty powerful argument:  running something in the REPL should
> give the same results as running it from a command line.  When things
> fail differently in different environments, the environments themselves
> become suspects.

If RecursionError stack traces were condensed, I would have them 
continue to be the same (condensed) in either interactive or batch mode.

>> I mostly agree with what you say, but I would like to see one change
>> to the default sys.excepthook: large numbers of *identical* traceback
>> lines (as you often get with recursion errors) should be
>> collapsed. For example:
>
> [...]
>
>> Try as I might, I just don't see the value of manually counting all
>> those 'File "<stdin>", line 3, in fact' lines to find out where the
>> recursive call failed :-)
>
> Yes, I see the smiley, but I would add specifically that the number of
> calls in the stack trace from a recursive function is rarely the
> important part.  When I write something recursive, and get *that* stack
> trace, I don't have to scroll anywhere to look at anything to know that
> I blew the termination condition(s).
>
> (I'm agreeing with you:  there is no value of counting the number of
> calls in the stack trace.)
>
> If I suddenly got tiny stack traces, I'd spend *more* time realizing
> what went wrong, until I retrained myself.


-- 
Terry Jan Reedy