[IPython-dev] ipython1 and synchronous printing of stdout

Barry Wark barrywark at gmail.com
Mon Jul 21 00:36:43 EDT 2008

On Sun, Jul 20, 2008 at 12:50 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> I don't have any time to look at this now, but we should have an
> interface in the interpreter that allow the registration of a callback
> that gets called or these things.
> Cheers,
> Brian

There are, I think, several "events" for which a frontend might want a
callback. Opening files, stdout/stderr output, and modifications to
the user_ns are some that come immediately to mind. Opening files
might be of interest if the frontend wants to notify the user that
there is file output to be retrieved from the engine, stdout/stderr
for the resason Gael outlines, and modifications to the user_ns to
allow the frontend to keep an up-to-date view of the user_ns (ala
Matlab's Workspace browser) without querying the the entire engine
user_ns after every executed block.

Apple's NSDistributedNotificationCenter API
seems like a good pattern for this task (I'm sure there are equivalent
APIs in other frameworks). Basically, the frontend can register for
notifications by name. The interpreter then fires notifications for
all events and they are passed on, by the notification center, to all
registered observers.

Just my 2c to start the discussion.


> On Sun, Jul 20, 2008 at 1:27 PM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>>> I can off course monkey patch the output_trap with my own write method,
>>> but this seems a bit ugly. What do the ipython1 developpers think the
>>> right way of doing this (and maybe modifying output_trap) is?
>> I went ahead experimenting, and created a subclass of output_trap gear
>> towards printing via a callback, as can be seen on
>> http://bazaar.launchpad.net/~gael-varoquaux/ipython/ipython-sync-frontend/annotate/1041?file_id=sync_output_trap.py-20080720174256-b1fz1ebbxl2ka4t9-1
>> I hope this approach is OK. By passing this this output_trap to the
>> interpreter I get the desired result, and I sync this approach is
>> reusable for any synchronous frontend, such as the one into which
>> ipython0 will, hopefully, morph one day.
>> Gaël
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev

More information about the IPython-dev mailing list