[IPython-dev] Extensible pretty-printing

[Robert Kern]

[PS: I'm subscribed to the list. Please don't Cc me.]

On 10/27/10 4:14 PM, Brian Granger wrote:
> Robert,
>
>> In the ticket discussion around my patch to restore the result_display hook,
>> Brian suggested that the real issue is what the extensibility API for this
>> functionality should be. I would like to propose the pretty extension as that
>> API. I propose that it should be integrated into the core of IPython as the
>> pretty-printer instead of pprint. pretty allows one to specify pretty-print
>> functions for individual types and have them used in nested contexts.
>
> This is at the top of my ipython tasks right now, but I have been
> finishing some sympy related stuff.  I agree with you that this is, to
> first order a great extension model for the display hook and I think
> we should support it.  There are some other issues though that we will
> have to figure out how to merge with this idea:

As far as I can see, this is entirely orthogonal to the choice of pretty as the 
API for configuring the str pretty-representation. pretty isn't really relevant 
to the problems below nor the reverse. There is no need to hold it up while you 
work out the rest.

> * We also want to extend the display hook to allow other (non-str)
> representations of objects.  For example, it would be fantastic to
> allow html, png, svg representations that can be used by frontends
> that support them.  Other frontends can fallback on the basic pretty
> print approach.  The question is how to integrate these different
> approaches.
>
> * To get these other representations of an object back to the
> frontend, we will have to move the payload API over to the PUB/SUB
> channel.
>
> I can imagine a few models for this...
>
> 1. We could extend the pretty printing API to allow the ability for
> the function to return different representations.  It could for
> example return a dict:
>
> {'str': the_str_repr,
>   'html; : the html repr,
>   'svg' : the svg repr}
>
> In this model it would be up to the registered callable to construct
> that dict in whatever way is appropriate.

Back when I did the ipwx refactor so many years ago, I had a DisplayTrap and a 
set of DisplayFormatters. The DisplayTrap had a list of formatters. Each 
formatter had an identifier. The DisplayTrap replaced the displayhook to record 
the object. Then, when the interpreter needed to reply to the frontend, it asked 
the DisplayTrap to add to the message. In turn, it asked each formatter to try 
to render the object and add that to the message like the dict above.

http://www.enthought.com/~rkern/cgi-bin/hgwebdir.cgi/ipwx/file/fe7abfcd0f69/ipwx/display_trap.py
http://www.enthought.com/~rkern/cgi-bin/hgwebdir.cgi/ipwx/file/fe7abfcd0f69/ipwx/display_formatter.py

This API only concerns itself with rendering the top-level object. It doesn't 
handle nested structures at all. I don't think it is reasonable to handle 
nesting in anything but text, but if someone wants to try that's fine. The 
responsibility for defining the API to handle that falls to the individual 
DisplayFormatters. I would have a PrettyDisplayFormatter that exposes the pretty 
API for adding functions for types. The rest of IPython shouldn't concern itself 
about the API beyond that.

> 2. We could look for special methods on objects and use those for the
> printing.  This is how sage works.

Entirely inflexible if it's the only option. There are way too many objects that 
we want to pretty-print that aren't modifiable by us. If individual formatters 
want to look at special methods (pretty looks for __pretty__, a PNG formatter 
could look for _latex_), that's fine, but it can't be the only way to extend.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco