[Python-ideas] Have REPL print less by default

[Franklin? Lee]

On Mon, Apr 18, 2016 at 11:51 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
> On 04/18/2016 08:41 AM, Franklin? Lee wrote:
>>
>> I don't want arguments like, "This can already be done, for yourself, if
>> you really need it." I use IPython's shell, with maximum output height,
>> and it was years ago that I used a terminal which I couldn't scroll.
>>
>> I want arguments like, "This will break my workflow."
>
>
> How about:  the default REPL is a basic tool, and the limitations of basic
> tools are what drive folks to seek out advanced tools. ?

The REPL is a basic tool for basic users, which is why it should "Do
the right thing" for people who wouldn't know better. I'm asking
whether this is the "right thing" for those basic users: Advanced
users are the ones who can use more than basic info.


> Or Marc-Andre's:
>> I [...] don't think the defaults should be such that you have to
>> enable some variable to see everything. This would make debugging
>> harder than necessary, since often enough (following Murphy's law)
>> the most interesting information would be hidden in some ellipsis.

I think it's a high priority not to lose information that was hidden.
In my proposal, I said that there should be a way to access it, right
after you cause it, which is very different from needing to enable a
variable.

If not for (memory) performance anxiety, I would've proposed that the
info would be stored indefinitely, or that you would always be able to
access the last three (or something) outputs/stacktraces, because I
was concerned about typos causing exceptions that would then push the
interesting stacktrace out.

(Hey, that's another possible proposal: maybe syntax/lookup errors on
the "R" part of "REPL" shouldn't count toward `sys.last_traceback`.
Has anyone here ever needed to debug or reprint syntax errors coming
from compiling the command they just entered?)


> Or even Nick's (that you snipped):
>>
>> 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.

I read this as, "It'll be more complicated, so it MIGHT be buggy."
This seems solvable via design, and doesn't speak to whether it's
good, in principle, to limit output per input. If you still think it's
a good reason, then I probably didn't understand it correctly.


On Mon, Apr 18, 2016 at 2:39 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
> "Franklin? Lee"
> <leewangzhong+python at gmail.com> writes:
>
>> On Apr 18, 2016 3:25 AM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
>> > 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
>>
>> I don't want arguments like, "This can already be done, for yourself,
>> if you really need it."
>
> That's your prerogative.
>
> This forum is for discussing whether ideas are right for changing
> Python, though. Arguments such as “This can already be done, for
> yourself, if you need it” are salient and sufficient, and not to be
> dismissed.
>
>> I want arguments like, "This will break my workflow."
>
> You're free to solicit those arguments. You'll need to ackonwledge,
> though, that they are in addition to the quite sufficient argument of
> “already possible for people to get this in Python as is, if they want
> it”.

When they are presented as a solution to "my" problem, they are, to be
short, irrelevant. They try to address the speaker's need for the
feature on their own machine, when I am asking for opinions on both
the usefulness and harmfulness of such a feature, and the principle
behind the feature. They are distracting: people are talking more
about whether I can do it "myself" than how it's bad to have this, or
how it wouldn't help who I want to help.

Even if they weren't trying to solve "my" problem, I had non-advanced
users in mind, and these solutions tend to be about what advanced
users can do. I felt the need to point out what I'm looking for in the
arguments, because people are telling me how *I* can have this feature
by, for example, writing a display hook, or plugging into pprint.