[IPython-dev] Re: notebook composition UI thoughts

[Fernando Perez]

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 
> work.

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 :)

Cheers,

f