Inspired by the LWN article (https://lwn.net/Articles/815265/) about enhanced pretty-printing, I implemented a modified repr/displayhook that makes uses of the builtin pretty-printing of the DomTerm (https://domterm.org) terminal emulator.
See this screenshot http://domterm.org/images/python-pretty1.png which shows the *same* REPL session displayed in two "panes" of different widths. More information here: http://domterm.org/Python-tips.html The idea is that Python handles *what* to print, but the terminal emulator (or IDE like Jupyter or ipython) decides where to break the lines, add indentation, etc. The terminal knows the line-width and can dynamically re-format the output if the width changes - even for previously-printed output (and even for an exited python command). This is just like many terminals will automatically re-wrap over-long lines - but on steroids. This required a rather small amount of code to insert some extra escape sequences to delimit grouping, optional line-breaks, and indentation - see here: https://github.com/PerBothner/DomTerm/blob/master/tools/python/domterm/utils.py I'm not suggesting pprint should depend on the terminal being able to do pretty-printing, but I suggest that at the least type-specific pretty-printers should use overrideable methods to define grouping and optional newlines. That would allow an IDE or terminal-specific code to by-pass the Python pretty-printing and instead have the terminal/IDE do it. As an example you can see how Kawa does it - look for the writeList method in https://gitlab.com/kashell/Kawa/-/blob/master/gnu/kawa/functions/DisplayFormat.java This calls conceptually abstract methods like startLogicalBlock and endLogicalBlock (to delimit groups) and writeSpaceFill (to mark optional newline). Going beyond pretty-printing, I've been thinking about a "data explorer" where you click on buttons to hide/show more detail. I'm most familiar with this from the JavaScript consoles of Firefox and Chrome. I implemented a "finite" version of this idea for Kawa - see here: https://domterm.org/saved/dt-prettynested.html Note the triangles are clickable butoons that hide or show detail (and how this is integrated with pretty-printing). This prototype only handles the case where all the displayable data is printed, even though some may be initially hidden. To explore larger or circular data structures you'd want a protocol where the terminal/IDE can request more data. (I have a rough design for this, but that is a different discussion. Let me know if this would be interesting.) (I am not primarily a Python programmer, but it's been fun figuring out how to implement Python/DomTerm integration.) -- --Per Bothner p...@bothner.com http://per.bothner.com/ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/Z5CZH7ODJOZLPTY5S7TRWYGZVBAGU4SP/ Code of Conduct: http://python.org/psf/codeofconduct/
