[IPython-dev] Extensible pretty-printing

[Brian Granger]

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:

* 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.

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

For example, when the display hook get an object, it would look for
methods with names like:

foo._html_repr
foo._svg_repr

And then call those to get the various representations.

The downside of this model is that the actual objects have to be
modified.  But in some cases, this would be really nice and nicely
encapsulate the logic in a way that doesn't depend on IPython.  The
other benefit is that we can also introduce top-level functions like
repr_html, repr_png, etc. that users could use to get a particular
representation of the object displayed in the frontend.  This would be
nice in inner loops, where display hook won't be called.

Any thoughts on which of these models sounds better?  Any other good models.

Cheers,

Brian

[the thing that is motivating me on this is the desire to use
matplotlib's latex rendering to get png+latex representations of sympy
expressions displayed in the frontend.]

I think this type of capability would set off a wildfire of people
making really cool representations of their objects.




> Incidentally, this would resolve this issue by allowing the user to specify a
> pretty-printer for floats:
>
>   http://github.com/ipython/ipython/issues/issue/190
>
> --
> 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
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com