[IPython-dev] ipython1 and synchronous printing of stdout
Thu Aug 7 08:44:50 CDT 2008
I appologize. In my haste to reply, I'm afraid that my speed may have
come off as impatient. Let me try again:
Although I was initially a bit offended by your remarks, I realize
that we all have too much to do and not enough time to do it. I am not
(and won't be) offended if you don't want to use the notification
framework. We should always prefer working code and I am looking
forward to benefiting from your efforts, no mater what architecture
On Wed, Aug 6, 2008 at 3:54 PM, Barry Wark <firstname.lastname@example.org> wrote:
> On Wed, Jul 30, 2008 at 8:55 PM, Gael Varoquaux
> <email@example.com> wrote:
>> 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
>> 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,
More information about the IPython-dev