[IPython-dev] twisted process pool...
gael.varoquaux at normalesup.org
Wed May 14 12:21:42 EDT 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 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
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