[IPython-dev] Extensible pretty-printing

[Brian Granger]

All,

On Wed, Oct 27, 2010 at 7:52 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> 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.

I agree with this.

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

Yep

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

Yep

> 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?

I think this sounds good.  But, the important point is that the pretty
model will be *the* model for our basic str repr in displayhook, but
merely an extension.

Cheers,

Brian


> Cheers,
>
> f
> _______________________________________________
> 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