[IPython-dev] ipython1 and synchronous printing of stdout

[Barry Wark]

On Wed, Jul 30, 2008 at 8:55 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> Hi,
>
> Sorry for the silence, I have been working my ass off on a release of
> Mayavi. Now I can go back to working on ipython.

No problem. I'm not finding tons of time to play either.

>
> On Sun, Jul 27, 2008 at 10:02:08PM -0400, Barry Wark wrote:
>> Taking a bit of my own medicine—that working code is better than
>> awesome theory—I've checked in the ipython-notification branch and
>> proposed it for merging into trunk. It includes a functional spec in
>> /blueprints (it's a bit tounge-in-cheek; I hope no one is offended) as
>> well as an implementation of the NotificationCenter I've been
>> discussin in IPython.kernel.core.notification.
>
> I had a look at that. I seems to me like a (good) textbook implementation
> of the patterns we are discussing. I still fail to see the point of
> having this in Ipython, at least at the state we are in right now. My
> point is that there are many implementation of such frameworks. The one
> you have developed is a simple one, but when you start using it a lot,
> you will need to add features, like delegations, or ordering the
> callbacks. Also, something that is very important is how does this blend
> in the code people write? How do you make it easy for people to write
> notifications without thinking too much about it, and registering
> handlers (hint decorators are cool). But once again, this looks a lot to
> me like traits 1. I am not trying to sell traits here, I don't think
> IPyhton should use traits, I am just flashing a warning: this smells like
> weel reinvention, and on top of that developing a framework, which is
> something you want to limit as much as possible: we already have too many
> frameworks. I have the feeling every single person coming to develop an
> app using Ipython will already have his notification framework (traits,
> cocoa, does Qt have one?). So now he will to write adapting code to use
> your framework.

Yes, but I claim writing an adaptor layer for each GUI toolkit at the
level of ipython.frontend is better than writing the same in
ipython.kernel.core.

>
> Now there is value in having an iptyhon-specific notification layer, and
> it is not having uniform code across backends; matplotlib tried that, and
> it doesn't bring much value, amongst other things because the backend are
> anyhow riddled with toolkit-specific code. The value is that we could
> think of network-transparent notifications. That is much harder
> (obviously, the simple problems don't need solutions), and I would like
> to know if twisted doesn't provide this kind of service.

I think you've misunderstood the point. I am not trying to create a
universal GUI toolkit. I am concerned with notifications of events in
the core -- things that have nothing to do with the GUI toolkit. It's
up to the frontend writers to decide (1) what to do with those events
and (2) how to translate their GUI tookit's UI events into appropriate
calls into the ipython API.

>
> I guess my point is not that we shouldn't do this, but that we should do
> this when the need arises, and not now, for no benefit. Doing this too
> early is a good way of getting it wrong. In addition this will just slow
> our progress towards getting frontends and we absolutely do not need this
> to get the simple frontends. I am not going to spend anytime on this, and
> spending too much time on this is a good way of not having any useable
> code for a long time, I believe.

That's your choice. You can write your code as you wish.

>
> Sorry, not only am I not paid to worry about distant future, or
> network-transparency problems, I am also having difficulties being
> interested in something that I cannot specify properly because it doesn't
> answer a problem I have. I am not in the business of making a framework,
> I am in the business of making a widget. The whole notification framework
> stuff, for me, will be done in traits, because this is what we use all
> over our apps, because we have a lot of code that works well with it, and
> because is it a mature and powerful library. I develop my apps using
> traits, and I want an ipython widget to plug in my apps. If the objects
> used internally in the ipython widget are standard object like dicts or
> lists, I can use traits without any problem. If there are part of a
> notification framework that I have to adapt to, I probably have to double
> the size of my codebase. Let us see where we really need this framework.
> Maybe it can also be developed in a subclass of the standard objects we
> use in ipython, say a different frontend base class?
>
> I hope I am not being to rough or criticizing too much your software
> engineering efforts. I am just trying to be practical and figure out how
> to ship software that is useful to users (and yes this includes
> open-source software) in a reasonable amount of time. And the basis of
> agile methods is to get it working, ship it to your users, see the
> limitations in your implementation, refactor, ship it again, always
> focusing on what benefits to your users, rather than on the architecture
> or the software engineering, which is a tool, not a goal.

Fine. You have your requirements and if you don't have time to
consider alternatives, that's fine with me. I think going down the
road you've chosen will force others to recreate much of the
functionality you're working on, but it doesn't seem that you have
time to think about the more general case.

>
> As for your code, if you want to merge it in, it is fine by me, but I am
> afraid it won't be used for a while, and when we get to use it, we might
> want to change it because we have more insight on our problems.

Isn't that always the case?

>
> Thanks for bringing up on interesting discussion,
>
> Gaël
>