[IPython-dev] Renumber cells for nbconvert

[Sylvain Corlay]

Forcing renumbering in nbconvert would still be useful when converting
to script. Spyder for example has an "outline explorer" that gathers
all the cell separators in a Python file, since 2.3, (# In[*], #
<codecell> and # %%), possibly generated from nbconvert. In this
context, it would make more sense to use the natural ordering than the
execution order of the notebook.
S.

On Thu, Sep 18, 2014 at 9:14 PM, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
>
>
> On Thu, Sep 18, 2014 at 6:08 PM, Jon Wilson <jsw at fnal.gov> wrote:
>>
>>
>> On 09/18/2014 05:41 PM, Doug Blank wrote:
>>
>> On Thu, Sep 18, 2014 at 5:44 PM, Jon Wilson <jsw at fnal.gov> wrote:
>>>
>>> Hi Thomas,
>>> Yes, it does break that, which is unfortunate.
>>
>>
>> Jon, further reflection in the forced renumbering of cells (even when
>> clearing output) seems like a Really Bad Idea.... it is mucking around with
>> the reproducibility of the notebook---sorta like photoshopping a model to
>> make them like they don't. But, what about an automatic *labelling* of
>> cells? I'm thinking about a tool that could add a markdown cell above each
>> code cell that could label it, like the attached picture.
>>
>>
>> Hi Doug,
>> I like the attached screenshot, but I'd want to muck around with the CSS a
>> bit.  The positioning of the cell numbers off the to left makes them a draw
>> for the eye when you're looking for index-like information.  I think that
>> de-emphasizing those numbers and moving the sequential cell numbers off to
>> the left would be good.  But, the most important thing is to be able to find
>> what the presenter is talking about, and this already accomplishes that.
>>
>> Regarding reproducibility, renumbering the cells might actually improve it
>> in some cases.  If I've been working on a notebook for a while, I sometimes
>> have executed and re-executed various cells so many times that, if you
>> executed the cells in the order listed, you would use things before they
>> were defined.  Example: define a variable, then make two figures.  Then edit
>> the variable definition, re-run it, re-run one of the figures, then change
>> it back and run that figure again.  Now, the order of the cell numbering is
>> figure 1, definition, figure 2.  If you ran the cells in that order, it
>> would raise an exception on figure 1.  If you re-numbered the cells, then
>> you would run the cells as definition, figure 1, figure 2, and everything
>> would be fine.  Of course, all that is just sloppy discipline on my part and
>> an argument for periodically restarting the kernel and running everything
>> from the beginning.  But sometimes that is too expensive to do.
>
>
> Using a memoization patterns can be very useful for quickly regenerating the
> results of a long-running computation (although that comes with all issues
> inherent in caching data and adding state to your notebook, so buyer
> beware).
>
> I've had some success with joblib [0] in the past to manage caching.  One
> nice feature is it takes a cryptographic hash of numpy arrays that are
> provided as input to a function, so it's able to efficiently determine
> whether a function you want to memoize has had as input in the past some
> arbitrarily filled out numpy array, making it very straightforward to
> memoize functions that have numpy arrays as input.
>
> [0] https://pythonhosted.org/joblib/
>
> -Nathan
>
>>
>>
>>> What about automatic figure numbering?
>>
>>
>> Then we can treat code cells like figures, and renumber both, for
>> reference purposes.
>>
>> I like it.  The only thing I would change is that I would not number every
>> code cell.  When we're talking about notebooks, we're only very rarely
>> talking about the code itself.  Instead, plots and tables and numbers are
>> the most important things.  So if I had my "druthers", only cells that
>> produce meaningful output would be numbered.
>>
>> Thanks for all the great ideas, guys!
>> Regards,
>> Jon
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>