[IPython-dev] Re: notebook composition UI thoughts
rkern at ucsd.edu
Wed Jul 6 15:49:21 EDT 2005
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. In this case, I think it means the following stories (which happen
1. I just made a typo at "In :". I place my cursor back at the
typo and correct it. I press Enter to reexecute. The cell is visually
replaced by an "In :" cell with the new code. The "Out:" cell
has been replaced by "Out:" with the results of executing the new code.
2. I now want to change a value in "In :"'s code and reexecute
the cells that follow it, but only if they are still visible in the
sheet. Thus, "In :" --> "In :" and "In :" --> "In :", etc.
3. I add an "In :" that references "Out:". I change a value
in "In :" and reexecute cells 36--38. "Out:" (was "Out:")
doesn't change; I realize I am being silly and actually assign the value
I need to a variable and use that instead.
4. Since I find that I am doing this dance quite often, I assign the
appropriate cells to a macro that references the variable I keep
changing. Now I just reassign that variable and use that macro over and
5. I start a new sheet and specify that I want a fresh interpreter
instance. My first input cell is "In :".
This is not to say that other execution semantics would not be better
suited, but I think that they are much more difficult to implement and
really aren't what Toni and Tzanko signed on to do. If you wish to
contribute code that does implement these fancier semantics, we will
consider using it in addition to the Simplest Way Kern Can Think Of
rkern at ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
More information about the IPython-dev