Currently pprint.pprint() and other methods have a default width argument of 80. Using pprint.pprint() while debugging on a fairly wide monitor is quite annoying with this default. It’s obviously easy (if not also a tad annoying) to pass an explicit width argument, but then the moment you create a new split or resize the terminal you’re back to being annoyed again.
We have shutil.get_terminal_size and os.terminal_size, and I think it would be a good small quality of life improvement to use that as a default instead of 80.
I often have output that would benefit from using the wider terminal width available in full screen mode.
I think that the reason for rejection was weak. If students wonder why their output doesn’t match the teacher’s exactly, that’s a “teachable moment” right there.
I find it unlikely (though not impossible) that people would write programs that care about the exact layout of pprint() output. If you’re parsing such output, you have to handle arbitrary line breaks anyway.
A possible way forward would be to add global state to the module that affects the default width used by the convenience function pp() only. E.g. if you call pprint.set_pp_width(N) it sets the default width used by pp() to N, and if you leave N out it uses shutil.get_terminal_size().columns (using a lazy import). And maybe we could add a
Alternatively, assuming that teachers tend to use pprint in their examples instead of pp, we could just make pp() inquire the terminal width, leaving pprint() alone. (There’s a bit of a performance concern here, so it should probably cache the value, which means we’d still need a way to clear that cache, e.g. the set_pp_width() function I proposed above.)
As yet another altermative, if PEP 713 (Callable Modules) were to be accepted we could define the __call__() function as using the terminal width by default.
Maybe that detailed re-evaluation of the original close decision (or at least a link to it) would be useful to post as a comment on the issue, along with a re-opening it for discussion given the continued interest from users and the fact that only one core dev has opposed the change, with several in favor?
For what it’s worth, I’m not a maintainer of the pprint module, though I’ve spent a decent chunk of time reviewing and mentoring at least one decent-sized contributor PRs for it in the past, and use it a decent amount myself, and I’d certainly find it much more useful in most cases if it automatically resized (and for those where I wanted it a different size, I’d be more than happy to pass a parameter, given 80 columns may or may not be near the fixed size I actually want anyway).
Also, I’m not a professional Python instructor, though much of my time is spent teaching, tutoring and mentoring students (typically scientists rather than software engineers) in Python, mostly one on one or in small groups. I’d personally find it rather far fetched that a student would be seriously confused by both their and the instructors’ output matching the terminal’s width, as this is how textual output nearly always works in the graphical applications that newer students tend to be far more familiar with. And if it is, the teacher can simply explain that pprint output adapts to the terminal width by default, and can wrap to a different width using the width keyword argument.