"[Python-ideas] dunder methods for encoding & prettiness aware formal & informal representations" https://mail.python.org/archives/list/[email protected]/thread/OQPPJ7SNM5CZUI5RYT5R4Z6YZWMNNTZS/
discusses how pretty printing could be extended. I'll bump the thread On Tue, Mar 31, 2020, 5:54 PM Per Bothner <[email protected]> wrote: > 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 > [email protected] http://per.bothner.com/ > _______________________________________________ > Python-ideas mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/Z5CZH7ODJOZLPTY5S7TRWYGZVBAGU4SP/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/DAGZLAARTTUF7IOS4IBHFM3ZS7O2GC3B/ Code of Conduct: http://python.org/psf/codeofconduct/
