[IPython-dev] ipython1 and synchronous printing of stdout

[Gael Varoquaux]

On Sun, Jul 20, 2008 at 09:36:43PM -0700, Barry Wark wrote:
> There are, I think, several "events" for which a frontend might want a
> callback. Opening files,

Hum, in what sens? What would trigger this event?

> stdout/stderr output,

Sure, this is why I came up with SyncOutputTrap, that allows me to pass a
callback to write. I add a wx.Yield() in this calback and my UI can
refresh each time you write something to stdout/stdin.

> 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.

Hum, I am not too excited about firing events when the namespace gets
updated. This could slow things down a lot. I general I am not too
excited about having events fired all over the place. This can lead to
tedious code with getters and setters and a udge performance loss. I am
much more interested in using objects with a standard interface (such as
a file, for instance) and then, if you want getters and setters, or
the possibility to add callabcks, you do it in these objects. 

> Apple's NSDistributedNotificationCenter API
> (http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSDistributedNotificationCenter_Class/Reference/Reference.html)
> 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.

Well, I don't really like this kind of code. I find it clunky, and you
end up have notification registrations all over the place (reminds me of
wx). I actually prefer a lot the traits model, or the VTK model, AFAIK,
where objects can be there own observers. As a result you do not have
notifications blending in objects where they do not belong. For the core
frontends, obviously, we do not want to add a dependence to traits, but I
must imagine I cannot imagine going much further without it. To take your
example of updating the namespace view, all you have to do is to pass a
traited dict, instead of a dict, to the interpreter as a namespace. Then
you can have your namespace update automatically (AFAIK Robert is
actually working on a branch where he does that).

If we start adding callbacks whereever we need them, I am worried we'll
end up with callbacks everywhere. I think we need to add callback only
where they are absolutely necessary.

My two cents,

Gaël