[IPython-dev] Extensible pretty-printing

[Fernando Perez]

Howdy,

On Wed, Oct 27, 2010 at 8:37 AM, Robert Kern <robert.kern at gmail.com> wrote:
> 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.

I've been looking carefully at the CommandChainDispatcher code, since
you raised the design points about it in the discussion on github.  I
agree that it's a very reasonable design pattern and we're likely to
end up re-implementing something quite similar to it if we discard it,
so there's no need to.  It just needs a few tests to pin down the
expected functionality for the long run, and I'd like to change the
notion that undispatched functions in the chain can modify the
arguments along the way.  That just seems to me like a source of
hard-to-find bugs and I fail to see the need for it.  But otherwise I
have no problems with it.

As for the rest of the discussion and the points Brian brings up, it
seems to me that we can proceed in steps:

1. Bring pretty (as-written) back to life as a starting point.  We
never meant to nuke it for ill, and we seem to all agree that it's
fundamentally a good approach to start off.

2. We can then consider extending the model, from only returning the
'data' field we use today:
http://ipython.scipy.org/doc/nightly/html/development/messaging.html#python-outputs

to multiple fields as Brian mentioned.  We already effectively return
a dict, it's just that now we only have one 'data' field.  Extending
this to 'str', 'html', etc is fairly natural.

We can at that point discuss how these other fields would be filled
out, whether by registering formatters along the lines of your old
ipwx code or some other mechanism...

It seems to me that the best way forward would be for you to set up a
pull request that restores pretty's functionality, ensuring that it
works both on the terminal and the Qt console.  From there we can
polish things and think about the more extended model.

How does that sound to everyone?

Cheers,

f