[IPython-dev] twisted process pool...
Tue May 13 21:28:01 CDT 2008
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
> 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.
More information about the IPython-dev