[Python-ideas] Have REPL print less by default

Nick Coghlan ncoghlan at gmail.com
Mon Apr 18 03:25:24 EDT 2016


On 18 April 2016 at 15:32, Franklin? Lee <leewangzhong+python at gmail.com>
wrote:

> On Apr 17, 2016 11:24 PM, "Ben Finney" <ben+python at benfinney.id.au> wrote:
> >
> > Surem, that would be a good place for it. I think that's much more
> > feasible than changing the behaviour of ‘repr’ for this purpose.
>
> Huh? I never meant for any change to happen to `repr`. The desired
> behavior is, "Set default: Each command entered into the REPL should have
> limited output (without loss of capability for a newbie)." The proposal is
> to have the REPL determine when it's going to output too much.
>
A few tips for folks that want to play with this:

- setting sys.displayhook controls how evaluated objects are displayed in
the default REPL
- setting sys.excepthook does the same for exceptions
- the PYTHONSTARTUP env var runs the given file when the default REPL starts

So folks are already free to change their REPL to work however they want it
to: set sys.displayhook and sys.excepthook from a PYTHONSTARTUP file

Changing the *default* REPL behaviour is a very different question, and
forks off in a couple of different directions:

- improved defaults for teaching novices? Perhaps the default REPL isn't
the best environment for that
- easier debugging at the REPL? Perhaps pprint should gain an
"install_displayhook()" option that overwrites sys.displayhook and
optionally allows enabling of an output pager

Since the more the REPL does, the more opportunities there are for it to
break when debugging, having the output hooks be as simple as possible is
quite desirable. However, making it easier to request something more
sophisticated via the pprint module seems like a plausible approach to me.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160418/2ad9a86c/attachment.html>


More information about the Python-ideas mailing list