Using notebooks as informal packages - (non)exportable code cells

[Tony Hirst]

Recipes such as http://jupyter-notebook.readthedocs.io/en/stable/examples/Notebook/Importing%20Notebooks.html provide a means for importing the contents of a notebook as a module, but they do so by executing all code cells.

My development notebooks tend to have functions defined as well as lots of little test cells that test the functions, or that include literal bits of code that I'm trying to test before working them up into a function.

Sometimes I want to make use of the functions in other notebooks, but don't want to run all the other bits of code.

I was thinking it might be handy to define some code cell metadata ('exportable':boolean, perhaps), that I could set on a code cell to say whether that cell was exportable as a notebook-module function or just littering a notebook as a bit of development testing.

The notebook-as-module recipe would then test to see whether a notebook cell was not just a code cell, but an exportable code cell, before running it. The metadata could also hook into a custom template that could export the notebook as python with the code cells set to exportable:False commented out.

Is anyone using such a recipe? Does it help with workflow?

--tony

[Johannes Feist]

In case you are not aware of the possibility, what I have been doing for this case is the "standard" python approach, i.e., simply guard the part that shouldn't run upon import with

if __name__=='__main__':

statements. When you execute a notebook interactively, __name__ is defined as '__main__', so the code will run, but when you import it with the hooks you mention, __name__ is set to the module name, and the code behind the if doesn't run. Of course it makes the notebook look a bit more ugly, but it works well, allows to develop modules as notebooks with included tests, and has the advantage of being immediately visible/obvious (as opposed to metadata).

Best,

Johannes

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.
To post to this group, send email to jup...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/eba8e9fe-2173-4917-adb4-89a802f35b26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Johannes Feist
IFIMAC & Departamento de Física Teórica de la Materia Condensada
Universidad Autónoma de Madrid
johanne...@uam.es

[Johannes Feist]

Yeah, that's true. You can use an explicit display(last_line), but it's not quite as convenient as just displaying the last line explicitly. 

On Sat, Mar 24, 2018 at 10:31 PM Tony Hirst <tony....@gmail.com> wrote:

Good spot - but if I do that, then the last line in the block doesn't  return a displayed output? Which I was using for testing purposes in the dev notebook?

--tony

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/c69e6828-57b4-46bb-9e7a-06247de626f9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Yuvi Panda]

Check out https://github.com/ipython/ipynb. It does something similar to what you want, although I much prefer your explicit tagged solution to its heuristics.