[IPython-dev] Re: notebook composition UI thoughts
Fernando.Perez at colorado.edu
Wed Jul 6 15:34:50 CDT 2005
Robert Kern wrote:
> Hans Meine wrote:
>>On Wednesday 06 July 2005 18:24, Michael Tobis wrote:
>>>[...] For this to make sense I need a new python session (or at least a
>>>fresh namespace) invoked every time I make a change in the
>>>middle of a document. I need anything after the insertion point that
>>>changes to be highlighted and flagged, and I need multiple undos.
>>This goes into the direction I pointed out in one of my user stories: What
>>you'd really like to have is not to flag everything behind the point, but
>>just anything that depends on what you've changed. *Ideally*, you'd want
>>only those parts to be recalculated that actually depend on the changes.
> I think that drastically changing the execution semantics from what
> ipython currently does is out of scope for this summer's project. We are
> going to, wherever we can, do the simplest thing that could possibly
This is mostly a confirmation of Robert's position. Module-per-cell,
multiple-interpreters, auto-dependency analysis, etc. are all potentially
worthwhile ideas for certain contexts, but certainly not for a first shot. If
we can get an interactive environment which enhances the ipython command-line
experience with full-screen editing (to address the problem of endless
appending to a session), and basic functionality for supporting rich-text
documents (even if not rendered directly in real-time in the working window),
we'll have a useful system for many of us. This will also be an attainable
goal for Toni and Tzanko in the time allotted.
I should note that things like automatic dependency analysis are notoriously
difficult (I'd actually guess nearly impossible) in python. The language is
far too dynamic for that, and this is _exactly_ the same problem which has
made all restricted execution systems for python fail (to the point where
they've been removed from the standard library). The discussions on
python-dev on this issue, both in the context of security and of dynamic type
inference for optimization purposes, contain all the gory details.
But the basic point is that python has 'eval' and 'exec', both of which are
enough to thwart just about any reasonable attempt at dependency analysis. It
is true that in mathematica, the top-down flow of the text can be misleading,
as the time-flow of execution (only recorded by the prompt numbers) is what
really defines the in-memory status of the kernel. There are systems with
automatic dependency tracking and recalculation: spreadsheets like excel do
this, as well as systems like Mathcad. But those systems have much more
limited assignment semantics than python, so they can keep such a dependency
tree consistent at all times with reasonable effort.
I'd rather not provide such a system if it is going to have random
reliability. That's been exactly the position of python-dev on restricted
execution: since we can't guarantee it will work, and it can break almost
anywhere, we simply won't ship it (until someone can come along with a
solution shown to be robust). The extremely dynamic nature of python is what
makes it so flexible for many things, but it also carries a price.
On the multiple interpreters front, that's more likely in the near term.
There's a good possibility that the gui will be built with the ipython
'kernel' living in a separate process, to allow it to be restarted without
destroying the gui. If that is done, the basic infrastructure would be in
place for supporting multiple interpreters connected to different tabs in a
session or something similar. Not necessarily something to be implemented
initially, but it the scaffolding would be in place to make it possible.
And thanks to all for the feedback! It shows at least that there is a lot of
interest in such a system, though everyone's idea of their ideal toy is
obviously a bit different :)
More information about the IPython-dev