[Python-ideas] Have REPL print less by default

[Franklin? Lee]

On Apr 19, 2016 9:12 AM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
>
> 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).

But a local signal _is_ part of my original proposal:

    """Instead, it will print a few lines ("... and approximately X more
lines"), and tell you how to print more. (E.g. "Call '_more()' for more.
Call '_full()' for full output.")"""

    """Again, there should be a message telling you how to get the full
stacktrace printed. EXACTLY how, preferably in a way that is easy to type,
so that a typo won't cause the trace to be lost. It should not use
`sys.something()`, because the user's first few encounters with this
message will result in, "NameError: name 'sys' is not defined"."""

This also satisfies Terry Reedy's "reversibility" condition.

On Apr 19, 2016 10:03 AM, "Michael Selik" <mike at selik.org> wrote:
>
> On Tue, Apr 19, 2016 at 5:36 AM Franklin? Lee <
leewangzhong+python at gmail.com> wrote:
>>
>> On Apr 19, 2016 4:09 AM, "Paul Moore" <p.f.moore at gmail.com> wrote:
>> > Basic users should probably be using a tool like IDLE, which has a bit
>> > more support for beginners than the raw REPL.
>>
>> My college had CS students SSH into the department's Linux server to
compile and run their code, and many teachers don't believe that students
should start with fancy IDE featues like, er, syntax highlighting.
>
> That's probably because your professors thought you were more advanced
than other new Pythonistas, because you were CS students. If I were in
their shoes, I might chose a different approach depending on the level of
the course.

I meant to have two separate clauses:

- In my college, there was a server for compiling and running code. It
allowed people to do so without installing a compiler (e.g. on a
general-purpose school computer). It also gave a standard compiler to test
against. I did not learn Python in school.

- Many teachers, all over the world, do not believe in IDE features for
beginners. (Therefore, there will be many *students* which don't learn
about IDLE.) You can want them to stop thinking that way, but the students
will still be out there.

> > But that doesn't answer my question: would the proposed change hurt
your workflow?
>
> It might. Would it affect doctests? Would it make indirect infinite
recursion more difficult to trace? Would it make me remember yet another
command line option or REPL option to turn on complete reprs? Would it
force me to explain yet another config setting to new programmers?

Let's be clear about what I am proposing. I prioritize not losing info and
making it obvious how to get at that info. My suggestion was to show less
output *and* have a message at the end saying how to get the output.

It obviously should not affect doctests, since the output there is not for
humans. An implementation that affects doctests should be considered buggy.
Perhaps have an option to allow it, but affecting doctests by default would
be an actual backward incompatibility, since it changes how existing code
*runs* (i.e. not just output, but different logical paths during runtime).

My idea for tracebacks of mutually recursive calls: See which functions are
on the stack more than once, and if they keep appearing, pack them up. The
algorithm should not pack up calls which happen only once within an
apparent cycle, and it should be clear which order the calls come in
(outside of folded mutually-recursive calls, of course).

Example:
    File "<stdin>", line 1, in f
    File "<stdin>", line 1, in g
    [Mutually recursive calls hidden: f (300), g (360)]
    File "<stdin>", line 1, in h
    File "<stdin>", line 1, in f
    File "<stdin>", line 1, in g
   [Mutual-recursive calls hidden: f (103), g (200)]
  RuntimeError: maximum recursion depth exceeded
  [963 calls hidden. Call _full_ex() to print full trace.]

Or maybe the second f and g are also folded into the second hidden bit. And
maybe it checks line numbers when deciding whether to print explicitly (but
not when folding).

Would that output make indirect infinite recursion more difficult for you
to debug?

> I think a beginner understands when they've printed something too big. I
see this happen frequently. They laugh, shake their heads, and retype
whatever they need to.

I am not proposing this as a better error message, but because a flooded
terminal is loss of information. It is also good to have significant info
close together, to reduce effort (and thus mental cache) between processing
of related ideas.

Have you never needed to see the output of previous lines? Re-entering the
earlier line might not work if the state of the program has changed. This
happens at the beginner level.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160420/cebd5dd9/attachment-0001.html>