[IPython-dev] Extensible pretty-printing

[Fernando Perez]

On Thu, Oct 28, 2010 at 4:54 PM, Mark Voorhies <mark.voorhies at ucsf.edu> wrote:
> On Thursday, October 28, 2010 04:11:18 pm Fernando Perez wrote:
>> On Thu, Oct 28, 2010 at 4:00 PM, Robert Kern <robert.kern at gmail.com> wrote:
>> > I recommend exactly what I did in ipwx. The DisplayTrap is configured with a
>> > list of DisplayFormatters. Each DisplayFormatter gets a chance to decorate the
>> > return messaged with an additional entry, keyed by the type of the
>> > DisplayFormatter (probably something like 'string', 'html', 'image', etc. but
>> > also perhaps 'repr', 'pretty', 'mathtext'; needs some more thought).
>
> Would it make sense to use DisplayFormatter class names as keys?  That would
> avoid name collisions.  Clients wanting more abstract/semantic formatting names
> could use an auxiliary hierarchy of general->specific->formatter strings (e.g.,
> provided by the pretty module) to find the best match to a target formatting
> in the message (e.g., like resolving fonts in CSS).

I think Robert picked up this theme as well, so I'll reply in his
message to this idea...

>> If the latter, I'm not sure I like the approach of passing a dict
>> through and letting each formatter modify it.
>
> Given that the outputs should be independent (i.e., shouldn't be modifying each
> other), it seems like the main advantage of chaining the formatters would be to
> avoid duplicating work (e.g., the html formatter could work off of the string result).
> This could also be done by linking the formatters directly (e.g., passing a result-caching
> string formatter to the html formatter's constructor) as long as we know the order that
> they will be called in.

What I don't like about this is that it introduces a fair amount of
coupling between formatters: order dependencies and mutation of state.
 In my mind, these guys are just an example of the observer pattern,
and I think in that context the most robust implementations are those
that have minimal/zero coupling between observers.  Each observer gets
notified of the relevant event (output ready for display) and both
order of execution and failures of some shouldn't impact the others.

I'm not sure I see the real-world benefit of the tighter coupling and
I do see a cost...

Cheers,

f