Is there a cell tag convention to *skip* execution?

I’ve noticed a recurring question from Jupyter Book users that makes me wonder if it is part of a broader use-case in teaching and learning scenarios.

People often ask if there’s a way that they can mark a cell not to execute. I think that these cells are usually “prompt” cells that expect user input, and so they are expected to exist in-line with the other code cells, but cannot be executed when all the other cells are executed.

Has anybody ran into this use-case before, and do you know of any conventions (e.g. a cell tag called no-execute etc) that have been followed?

Curious if @mseal ever ran into this issue or if y’all settled on a particular pattern there.

1 Like

Generally it’s a dangerous practice to have code as a code cell that’s considered non-executable but in an executable location, because it’s not a primitive of the frameworking for Notebooks and compounds the out-of-order execution concerns that can arise currently present in Notebook development. Essentially if this were done it would harm the ease of reproduciblility and force all the interfaces to learn a new exception to normal operations.

There is a pending feature to add the ability to skip certain cells based on tag for papermill, in which the offending cells will be removed entirely (akin to a proprocessor action in nbconvert). But the recommended pattern out of the many conversations is to either A) remove code cells you don’t want to execute any more (leaning on version control for history), B) convert the cell to a raw cell type to preserve the text but avoid execution patterns, C) comment out all the contents of the cell as you would in temporarily disabled code in a traditional development environment, or D) convert the cell to quoted markdown and document when you might want to copy the snippet to a real code cell.

@MSeal

Essentially if this were done it would harm the ease of reproduciblility and force all the interfaces to learn a new exception to normal operations.

my use case is to add exercises to notebooks so that people can “fill in” code in that cell. All the given alternatives would make this process significantly more annoying when actually running through the notebook. (And they don’t prevent the reproducibility issues you mentioned, e.g. if an exercise gets out of sync with the code that’s run before.)

yeah I think that the usecase I had in mind seems pretty specific to teaching and learning (e.g. you’d have a cell like)

# Fix this code so it doesn't raise an error
print "hi"

or

import numpy as np
import matplotlib.pyplot as plt
data = ...
fig, ax = ...
ax.plot(...

stuff like that

1 Like

For me that is quite common for exercises. It could be great for that purpose to have such a support.

I think I am not following the usecase exactly to give helpful input. If it’s a teaching example, why not leave the cell as is with broken code until the student fixes it? If it’s not the be executed why not document what they need to do with a partial code snippet in the markdown above the blank cell they need to implement? I am guessing I am picturing the wrong mental image of the process you’re intending to use, so apologies if I’m off base here.

perhaps somebody could link to an example notebook or share an example of their use-case?

To be honest, because of error messages in the past I refrained from using that style (even though my colleagues did) because I preferred that the student version of a Jupyter Notebook should always be executable without throwing errors. It might present wrong numbers, graphics etc. though.

At https://github.com/1kastner/machine-learning-hype-or-hybris/blob/bc57d12f6a95ed06d9aeefbfa7960a18bd738a17/01%20einfuehrende-beispiele/01%20Tennisspielen%20bei%20verschiedenem%20Wetter.ipynb there are some sample Jupyter Notebooks. Currently the code is asked for by having a code cell with the comment # Schreiben Sie den Code in diese Zelle which roughly translates to Please write your code here. Here, if I could prodie a bit more help without raising any kind of errors that could be great.