# The pprint module should use the terminal width, where available **URL:** \ **Category:** Ideas\ **Created:** [June 10, 2023, 3:56pm UTC](https://discuss.python.org/t/the-pprint-module-should-use-the-terminal-width-where-available/27658 "2023-06-10T15:56:26Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![orf](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/orf/32/1889_2.png) [@orf](https://discuss.python.org/u/orf)\ **Post date:** [June 10, 2023, 3:56pm UTC](https://discuss.python.org/t/the-pprint-module-should-use-the-terminal-width-where-available/27658/1 "2023-06-10T15:56:26Z")
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 had a crack at implementing this here: [Comparing python:main...orf:pprint-terminal-width · python/cpython · GitHub](https://github.com/python/cpython/compare/main...orf:cpython:pprint-terminal-width), the change seems fairly small and self contained. Creating a new Github issue requires some discussion here first, so I wanted to see if anyone had any feedback or strong feelings on this issue? ---
**Author:** ![storchaka](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/storchaka/32/217_2.png) [@storchaka](https://discuss.python.org/u/storchaka)\ **Post date:** [June 10, 2023, 4:35pm UTC](https://discuss.python.org/t/the-pprint-module-should-use-the-terminal-width-where-available/27658/2 "2023-06-10T16:35:11Z")
It was discussed before and rejected. > > > BPO | \[29996\](https://bugs.python.org/issue29996) > \--- | :--- > Nosy | @freddrake, …@rhettinger, @merwok, @serhiy-storchaka, @eryksun, @MojoVampire, @zhangyangyu > PRs | \python/cpython#1008\ > > \\*Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.\*\ > > \\Show more details\\ > > GitHub fields: > \`\`\`python > assignee = None > closed\_at = \ > created\_at = \ > labels = \['3.8', 'type-feature', 'library', '3.9', '3.10'\] > title = 'Use terminal width by default in pprint' > updated\_at = \ > user = 'https://github.com/serhiy-storchaka' > \`\`\` > > bugs.python.org fields: > \`\`\`python > activity = \ > actor = 'serhiy.storchaka' > assignee = 'none' > closed = True > closed\_date = \ > closer = 'serhiy.storchaka' > components = \['Library (Lib)'\] > creation = \ > creator = 'serhiy.storchaka' > dependencies = \[\] > files = \[\] > hgrepos = \[\] > issue\_num = 29996 > keywords = \[\] > message\_count = 12.0 > messages = \['291187', '291195', '291196', '291197', '291238', '291239', '291240', '291243', '291244', '291248', '301157', '389149'\] > nosy\_count = 7.0 > nosy\_names = \['fdrake', 'rhettinger', 'eric.araujo', 'serhiy.storchaka', 'eryksun', 'josh.r', 'xiang.zhang'\] > pr\_nums = \['1008'\] > priority = 'normal' > resolution = 'rejected' > stage = 'resolved' > status = 'closed' > superseder = None > type = 'enhancement' > url = 'https://bugs.python.org/issue29996' > versions = \['Python 3.8', 'Python 3.9', 'Python 3.10'\] > \`\`\` > > \\ ---
**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\ **Post date:** [June 10, 2023, 10:03pm UTC](https://discuss.python.org/t/the-pprint-module-should-use-the-terminal-width-where-available/27658/3 "2023-06-10T22:03:23Z")
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. ---
**Author:** ![hugovk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hugovk/32/14505_2.png) [@hugovk](https://discuss.python.org/u/hugovk)\ **Post date:** [June 11, 2023, 7:04am UTC](https://discuss.python.org/t/the-pprint-module-should-use-the-terminal-width-where-available/27658/4 "2023-06-11T07:04:29Z")
For reference: - Issue: [https://github.com/python/cpython/issues/105630](https://github.com/python/cpython/issues/105630) - PR: [https://github.com/python/cpython/pull/105631](https://github.com/python/cpython/pull/105631) ---
**Author:** ![storchaka](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/storchaka/32/217_2.png) [@storchaka](https://discuss.python.org/u/storchaka)\ **Post date:** [June 11, 2023, 7:17am UTC](https://discuss.python.org/t/the-pprint-module-should-use-the-terminal-width-where-available/27658/5 "2023-06-11T07:17:56Z")
Closed the new issue as a duplicate. If duplicate issues are opened, we usually keep the oldest one or the issue with a larger discussion. ---
**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\ **Post date:** [June 12, 2023, 6:37am UTC](https://discuss.python.org/t/the-pprint-module-should-use-the-terminal-width-where-available/27658/6 "2023-06-12T06:37:18Z")
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.