[IPython-dev] twisted process pool...

[Gael Varoquaux]

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.

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.

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