[IPython-dev] twisted process pool...

[Gael Varoquaux]

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.

Gaël

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