use display instead of send_figure in inline backend hooks #2271
Conversation
This lets custom display functions (e.g. HTML) be used without any extra changes (see ipython#2234). possible downsides: * The previous code guarantees that only one format is published. If multiple figure formatters are registered, display will send them all. * If people for some reason disable the type-printers, then they will display the automatic figure display. Neither of these cases can come up unless people are messing with the formatters, and I think the first is actually an improvement.
|
Do we use |
|
Overall, I like this idea. In some situations, I could imagine a user would want multiple formats sent back. I also like using the standard display API calls as much as possible. |
I had thought so, but apparently not. Should I just remove it? |
I think this is just an artifact of concurrent development, where send_figure used to be used by display or something, but now it's just a parallel implementation of the same thing, which should be recombined. |
|
I think that |
|
On Thu, Aug 9, 2012 at 3:52 PM, Brian E. Granger
|
|
send_figure removed |
|
+1. Merging now. |
use display instead of send_figure in inline backend hooks This lets custom display functions (e.g. HTML) be used without any extra changes (see #2234). possible downsides: * The previous code guarantees that only one format is published. If multiple figure formatters are registered, display will send them all. * If people for some reason disable the type-printers, then they will display the automatic figure display. **Backwards-incompatible change** Note that `IPython.zmq.pylab.backend_inline.send_figure` has been removed, as `display()` can do the same job and we avoid an unnecessary special-case code path.
use display instead of send_figure in inline backend hooks This lets custom display functions (e.g. HTML) be used without any extra changes (see ipython#2234). possible downsides: * The previous code guarantees that only one format is published. If multiple figure formatters are registered, display will send them all. * If people for some reason disable the type-printers, then they will display the automatic figure display. **Backwards-incompatible change** Note that `IPython.zmq.pylab.backend_inline.send_figure` has been removed, as `display()` can do the same job and we avoid an unnecessary special-case code path.
This lets custom display functions (e.g. HTML) be used without any extra changes (see #2234).
possible downsides:
Neither of these cases can come up unless people are messing with the formatters, and I think the first is actually an improvement.