[IPython-dev] Extensible pretty-printing
Thu Oct 28 12:49:55 CDT 2010
On Wed, Oct 27, 2010 at 7:52 PM, Fernando Perez <firstname.lastname@example.org> wrote:
> On Wed, Oct 27, 2010 at 8:37 AM, Robert Kern <email@example.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.
> 2. We can then consider extending the model, from only returning the
> 'data' field we use today:
> 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?
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.
> IPython-dev mailing list
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
More information about the IPython-dev