[IPython-dev] ipython1 and synchronous printing of stdout

[Brian Granger]

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

I understand the benefits of traits, but we have already made a firm
decision to keep Traits (or any other compiled code for that matter)
out of the core of IPython.  IPython has to be able to run (at least
in principal) on non CPython implementation of Python.  Obviously, a
GUI frontend can use traits, wx, qt, etc., and the kernel relies on
Twisted which has compiled code.  But I it almost sounds like you are
proposing using traits in the interpreter class itself.

I am all for clever uses of Traits like Robert Kern has been thinking
about.  But, we do need a more general approach that doesn't rely on
Traits.

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

I tend to agree with this.  A bunch of random disconnected callbacks
makes an interface very disjoint.  See my upcoming reply to Barry to
the rest of my thoughts...

Cheers,

Brian

> My two cents,
>
> Gaël
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>