[IPython-dev] ipython1 and synchronous printing of stdout

[Gael Varoquaux]

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.

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.

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

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.

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.

Thanks for bringing up on interesting discussion,

Gaël