[IPython-dev] twisted process pool...

[Barry Wark]

Gael,

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
>