[Python-ideas] Have REPL print less by default

Franklin? Lee leewangzhong+python at gmail.com
Tue Apr 19 07:10:45 EDT 2016


On Apr 19, 2016 6:37 AM, "Chris Angelico" <rosuav at gmail.com> wrote:
>
> On Tue, Apr 19, 2016 at 8:10 PM, Franklin? Lee
> <leewangzhong+python at gmail.com> wrote:
> > This is a concern, but not one that is enough, by itself, to justify the
> > status quo. I disagree that it applies *anywhere near as much* here,
since I
> > don't see how it could break existing code. It will add a little
adjustment
> > and a little more work sometimes, but it doesn't require, say,
refactoring a
> > module, or every site page you ever downloaded.
> >
> >
>
> You have things slightly backwards. The status quo doesn't have to
> justify itself; a change does. Particularly when there's ANY backward
> incompatibility being brought in, the change has to be of material
> benefit, or it isn't going to happen.

No, I meant exactly what I said. He made it as an argument for the status
quo, and I said that, alone, it is a weak argument. I don't mean anything
beyond that. I posted this to find out potential issues and to see whether
less output (by default) is a decent goal to have. I am pushing for better
counterarguments. I am not suggesting that change should be the default
position.

The justification is already on the table: it will help people who are
still developing their skills and knowledge from getting too much
non-information. I expected arguments like, "When I was a newbie using the
REPL, this would not have helped me." Hardly anyone argued against it, but
just because it isn't discussed doesn't mean it isn't there.

>  Take, for example, this bug
> report:
>
> http://bugs.python.org/issue18018
>
> Notice that:
>
> * The error is clearly *incorrect*. The interpreter should not be
> raising SystemError in valid situations.
> * The old behaviour (raising ValueError) is also incorrect, but Brett
> offered it as a serious possibility.
> * Only the latest CPython was changed (the 'default' branch). It
> wasn't correspondingly fixed in 3.4 or 3.5.
> * Nobody ever even *considered* changing 2.7's behaviour.
> Backward compatibility CAN be broken, but it's a big deal.

Again, this is very different from the usual change. The incompatibility
that would be introduced is purely in the mind of the programmer:
-> "Oh, I am not getting the full output. But wait, there is a message
here."
<- "Wow, that is a lot of output. I suppose I will have to deal with it,
since it is already here."

The change in the bug report affects existing code (like code that tries to
catch SystemError) and googlability (existing resources). This change only
affects existing understanding, which is exactly what you are able to
change when you are sitting at a REPL. That is a huge difference with
respect to compatibility.

> Anything
> that can be done simply by changing a few local options is preferable
> to a core language change. Remember, anyone can redistribute Python
> with a modified site.py or other init script, or create a shortcut
> icon or shell script that invokes "python3 -i local_customizations.py"
> rather than simply running "python3" - and that script can do whatever
> you want it to, including changing sys.displayhook and sys.excepthook.

Again, these are things that the ones who are supposed to benefit from the
proposal are least likely to have available to them. Adding more
distributions to the ecosystem just makes it that much worse for them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160419/2deabd7b/attachment-0001.html>


More information about the Python-ideas mailing list