Re: [Python-ideas] Have REPL print less by default

On Apr 19, 2016 6:37 AM, "Chris Angelico" wrote:

On Tue, Apr 19, 2016 at 8:10 PM, Franklin? Lee 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.