[IPython-dev] Ipython frontend (async, sync, line or block oriented...)
barrywark at gmail.com
Mon Aug 18 09:57:38 EDT 2008
Sorry to take a couple of days to get back to you. I imagine you'll
see from my responses below that Gaël and I have differing views on
many of the design decisions that have gone into the curent frontend
package. That's good, I think. Let me give you a quick overview of our
goals in the frontend package and then I'll try to answer your
specific questions inline below.
The new IPython architecture (previously called ipython1) provides
many opportunities to separate the interpreter logic from UI (terminal
or GUI) logic. The frontend package is intended to make it easier
(though not trivial) to write frontends for the IPython interpreter
(where interpreter is IPython.kernel.core.interpreter.Interpreter, the
new ipython1 interpreter, or an
IPython.kernel.engineservice.IEngineService, the new ipython1
network/remote-aware IPython engine). There is a minimal functional
spec in docs/source/development that highlights the many use casess
we're trying to support. Briefly, they fall into three categories:
1) terminal-based frontends to a single Interpreter instance; very
similar to the current IPython UI experience
2) GUI-based frontends to a single Interpreter instance; this is the
category for both your and Gaël's efforts. Because the current
architecture is more separable, it will (hopefully) be easier to write
a GUI frontend to the Interpreter using the new architecture.
3) GUI-based frontends that make use of Twisted and the
IPython.kernel.engineservice architecture to provide a frontend to one
or more local or remote engine services. This is the goal of my (still
evolving) Cocoa frontend. I personally think this is a very promissing
new possibility for new UI's for interactive computing that we haven't
been able to explore with IPython in the ipyhton0 architecture.
Clearly, supporting a diverse range of use cases is a difficult task.
The goal of frontend is to provide whatever common functionality we
can identify that supports all three of these use cases, embodied in a
common base class FrontendBase. In addition, Gael has spearheaded
creating common base classes for each of these use cases. The
intention *is not* to create a common UI widget or event library for
IPython. Frontend writiers will still have to make decisions (and,
gasp, write code) to do "the right thing" with their UI system's
events and widgets.
Much of the original architecture for the frontend package was
motivated by use case #3 above. Hence, the frontend API is biased
towards treating code in blocks, rather than in lines. Gael's work
required line-oriented APIs. We're still struggling to resolve this
discrepancy. My goal in the next several weeks is to get the Cocoa
frontend (asyncrhonous, block-oriented) to a stable state, thus
stabilizing the frontend API for use case #3 and then to work on
integrating Gael's use case and code in a more seamless way.
more answers below...
On Sun, Aug 17, 2008 at 5:38 AM, Laurent Dufrechou
<laurent.dufrechou at gmail.com> wrote:
> Hi barry,
> I've started to take a look at your work. Seems from my quick review
> that you've done an asynchroneous frontend, block oriented while gaël
> as gone through the opposite :) sync and line oriented.
> In fact, seems you've used ipython1 while gael has gone ipython0 no?
> (If I remember well, ipython1 can instanciate remote ipython instance)
> Can you explain me the difference between block oriented and line oriented?
If you're familiar with Mathematica and Matlab, the UI of Mathematical
provides good model for block oriented input whereas the Matlab
command line (and the ipython0 terminal UI) provides a good model for
Line-oriented input is often more natural for people who are used to
command-line UIs. The distributed nature of the ipython1 architecture
(and the associated network latencies, loss of connections, etc.) make
line-oriented UIs difficult. In this case, the block-oriented UI is a
better model of the underlying architecture and so (I think) a better
UI paradigm because it helps the user's mental model come into line
with the software model.
Having used both Mathematica and Matlab, I've found that my Matlab use
patterns have migrated towards more block-like usage, so I personally
don't find the block-oriented UI a problem, but personal preferences
are, well, personal. We'll see.
> Line oriented is (I think) that you feed ipython instance with line
> and ipython instance determine by itself block bounds.
> So I think block oriented is that it is the frontend taht determine
> the bounds of the block?
Correct. This determination is an example of the common code that all
block-oriented frontends will require and is therefore included in the
More information about the IPython-dev