[IPython-dev] Extensible pretty-printing
Thu Oct 28 18:00:40 CDT 2010
On 10/28/10 5:41 PM, Fernando Perez wrote:
> On Thu, Oct 28, 2010 at 2:16 PM, Robert Kern<email@example.com> wrote:
>> Yes. The original pull request just tried to restore the status quo
>> anterefactor. It happened to use the CommandChainDispatcher because that was the
>> extensible API at the time. Since the larger issue of what the extensible API
>> *should* be was raised, I am now proposing that we should use pretty.py and
>> expose it as the API for people to extend the string representation used in the
> OK, it all makes sense now. Having looked at extensions/pretty in
> more detail now, I'm happy following through with your suggestion,
> modulo perhaps updating to the most current pretty if we have a stale
> one (I didn't check yet).
It's fresh. Also note that we have local modifications not in the upstream to
support the registration of prettyprinters by the name of the type to avoid imports.
> One last question: we don't want anything actually *printing*, instead
> we want an interface that *returns* strings which we'll stuff on the
> pyout channel (an in-process version can simply take these values and
> print them, of course).
pretty has a pformat()-equivalent. The original pull request had already made
> Right now we only have a single
> representation stored in the 'data' field. How do you think we should
> go about the multi-field option, within the context of pretty?
pretty does not solve that problem.
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). pretty
would just be the implementation of the default string DisplayFormatter.
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
More information about the IPython-dev