[IPython-dev] twisted process pool...

Gael Varoquaux gael.varoquaux@normalesup....
Wed May 14 11:21:42 CDT 2008

I understand your points. I do agree that finding an abstraction that can
be extended-enough to work for all UI concepts is hard. I think it is
doable, but please go ahead with your code. Ideas and vaporware should
never slow down the development of working code.


On Tue, May 13, 2008 at 07:28:01PM -0700, Barry Wark wrote:
> Although I agree with your premises (we want to avoid duplication of
> code between core/kernel and frontends), I've come to a different
> conclusion as I've worked on the Cocoa frontend. I'll share my
> alternative opinion here not to put yours down but to stimulate some
> discussion in the group...

> I feel that the InputStateManager as it's been outlined conflates two
> issues: handling user gestures and provided common functionality. I'll
> try to explain what I mean below.

> On Sun, May 11, 2008 at 9:31 AM, Gael Varoquaux
> <gael.varoquaux@normalesup.org> wrote:
> > On Thu, May 08, 2008 at 03:21:10PM -0700, Barry Wark wrote:
> >  > Glenn, would you or one of the other Twisted gurus help me understand
> >  > pyreadline is the appropriate place for integration with the Twisted
> >  > event loop in ipython1?

> >  I had a look at this problem a couple of month ago, and came to the
> >  conclusion the pyreadline was not suited for this, as it was not
> >  architectured for callback-driven mechanisms.

> >  I do believe there is a need for an abstraction of this kind to do
> >  impedance matching between user input, whether it be callback-driven or
> >  line-driven, which can be seen as a special case of callback-driven. We
> >  don't want functionality like testing whether a line is complete or
> >  dealing with history sitting in the front end as this code is not
> >  front-end-specific and we absolutely want to avoid repeating ourselves
> >  (in addition to really bad design from a CS point of view, this would
> >  most probably bring in inconsistent behavior between the different
> >  front-end. We don't want this code sitting in the engine or the
> >  controller as, first of all, we want to avoid extra round trips across
> >  the network, and, most important, sharing this information between
> >  different front ends (and thus users) would yield inconsistent behavior.

> But different frontends may _have_ very different behavior. For
> example, the behavior of a block-oriented (e.g. Mathematica's
> notebook) frontend is behavior than a line-oriented (e.g. terminal)
> frontend. For the block-oriented frontend, the builtin compile
> function is sufficient to determine if a block is executable. In
> addition, the expectation of users on different systems (e.g. OS X vs.
> Gnome vs. Windows) may be very different. To try to produce identical
> behavior across all frontends will frustrate everyone (ala Java).

> >  I have started something that we decided to call "InputStateManager", in
> >  the ipython1 code base. Its goal is to do exactly what you want: expose
> >  an abstraction layer above the controller, with an interface that can be
> >  used as callbacks in an event loop. This beast is currently very rough.
> >  It emerged organically when trying to adapt the ipython1 interpreter (I
> >  am not sure such a thing still exists) to the Wx frontend. It is not
> >  terribly well coded, and should be seen as a rough cut that is meant to
> >  be improved (I wouldn't feel sorry at all if not one line of this file
> >  was kept in the long run, I think only the interface is important, and
> >  it can still be improved). For me the guiding principle when working on
> >  the InputStateManager seems to be that if you use callbacks, you can fit
> >  you interface to any user-interaction paradigm.

> I think attempting to create our own UI event system (as
> InputStateManager is doing) is the wrong path. Matplotlib's multiple
> backends are a necessary evil (perhaps), but keeping them all in sync
> appears to be a huge (and somewhat unsuccesful) effort. Why not let
> frontend developers exploit the native event system. I think it's more
> useful for us to provide handlers for the actions the frontend might
> want to take (e.g. executing a block of code) rather than translate
> native events into our own event system. I've started this approach in
> the ipython1-cocoa branch in the frontend.frontendbase module.
> frontendbase provides common actions (e.g. check if a block is
> complete, execute a block, etc.) and provides hooks for implementers
> to override to e.g. display the result of an executed block.

> >  There still is a lot of work on the InputStateManager, and I won't be
> >  able to work on it before August (yes, that's long, sorry), but I don't
> >  regard this as my territory, and I'd be very happy if somebody hacks on
> >  it, especially since I believe different people hacking on it with
> >  different requirements will make the interface more general.

> >  Cheers,

> >  Gaël

  Gael Varoquaux,
  Quantum degenerate gases group
  European Laboratory for Non-Linear Spectroscopy
    University of Florence, Polo Scientifico
    Via Nello Carrara 1, I-50019-Sesto-Fiorentino (Firenze) Italy
    Phone: ++ 390-55-457242145      Fax: ++ 390-55-4572451
  ++ and ++
  Groupe d'optique atomique,
  Laboratoire Charles Fabry de l'Institut d'Optique
    Campus Polytechnique, RD 128, 91127 Palaiseau cedex FRANCE
    Tel : 33 (0) 1 64 53 33 23 - Fax : 33 (0) 1 64 53 31 01
    Labs: 33 (0) 1 64 53 33 63 - 33 (0) 1 64 53 33 62

More information about the IPython-dev mailing list