[IPython-dev] Extensible pretty-printing

[Fernando Perez]

On Thu, Oct 28, 2010 at 6:31 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> I am in the middle of lab (they are taking a quiz), so I don't have
> time to dig into the full thread ATM, but I do have a few comments:
>
> * The main thing that I am concerned about is how we answer the
> question i) "how do I (a developer of foo) make my class Foo, print
> nice HTML/SVG.  IOW, what is does the public API for all of this look
> like?

I would propose having a baseline protocol with the usual python
approach of __methods__.  We can define a few basic ones that are
auto-recognized:  __repr_html__, __repr_latex__, __repr_image__
(bitmap images), __repr_svg__, __repr_pdf__?  The system could by
default call any of these that are found, and stuff the output in the
repr output structure.

For the 'default' field of the repr dict, we'd use either __pretty__
if defined and pretty-printing is on, or __repr__ if pretty-printing
is off (I think that's how pretty.py works).

This lets classes define their own rich representations for common
formats.  And then, the complementary approach from pretty allows
anyone to define a formatter that pretty-prints any object that hadn't
been customized.

Though the cost of computing all of these every time does become a
concern...  There needs to be an easy way to toggle them on/off for
the user, so that you're not waiting for a bunch of

> * In the current IPython, displayhook is only triggered 1x per block.
> Thus, you can't use displayhook to get the str/html/svg/png
> representation of an object inside a block block or loop.  This is a
> serious limitation, that Fernando and I feel is a good thing in the
> end.  But, this means that we will also need top-level functions that
> users can put in their code to trigger all of this logic independent
> of displayhook.
>
> Like this:
>
> for t in times:
>    a = compute_thing(t)
>    print_html(a)  # This should use the APIs that we are designing
> and the payload system to deliver the html to the frontend.
>
> We should also have functions like print_png, print_svg, print_latex
> that we inject into builtins.
>
> What this means is that we need to design an implementation that is
> independent from displayhook and that is cleanly integrated with the
> payload system.

That seems reasonable, and it can reuse the same machinery from
displayhook.  Basically the displayhook does it when called and passed
an object, these functions do it by explicit user request...

Cheers,

f