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.