[IPython-dev] running all cells uninterrupted

Zoltán Vörös zvoros at gmail.com
Wed Apr 9 05:53:10 EDT 2014

Hi all,

I would like to raise a question about running multiple notebook cells. 
At the moment, there is an option for "running all below", which seems 
to collect all input cells, submit it to the server, and then wait for 
the results. However, if there is an unattended to error in one of the 
cells, then this
sequence immediately breaks, and the remaining cells don't execute.

I would like to suggest that there be an option for running all cells 
truly sequentially, meaning that the notebook should submit cell [N] 
only when the server returned from cell [N-1].

I would see at least three advantages. One is that the above-mentioned 
issue could be avoided (of course, this particular case could be solved 
by wrapping each cell in a try/catch loop on the client side). The other 
is that this would allow one to sequentially programme the content of 
the input cells. What I meant is something like this (pseudo-code)

In [1]:  i = 0
             ip = get_ipython()
             def set_input(i):
                 if i < 10:
ip.set_next_input('i += 1\nset_input(i)')

In [2]:     i += 1

and when the user hits "run all below" on In [2], i would be incremented 
9 times, and placed in successive input cells, each executed in turn.
Finally, if cells were collected and executed one-by-one, it would be 
possible to "supervise" the running of a longer calculation without 
having to interrupt the server: parameters could be tweaked or enquired 
about by simply inserting a cell in the notebook. Being able to get 
intermediate results on demand I would find quite useful.

I should also point out that this issue is related to a question that 
was posted here a couple of weeks ago 

I don't know what kind of architectural problems might arise from this 
scheme, but I really don't see any stumbling blocks. I don't advocate 
modifying anything in the core, and I believe, this could be done with 
minimal effort (I would be more than happy to contribute, if the scheme 
is viable) on the client side. Perhaps, some of the developers could 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20140409/3e51c46c/attachment.html>

More information about the IPython-dev mailing list