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.
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.
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.)
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.
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.
If you’re writing tests for students to write code to make pass, those assertions should fail when executing the notebook. (assert, ipytest, nbval) Are students then expected to change the cell back to a code cell so that the code in the notebook runs?
You can also change the cell type to raw, but that lacks syntax highlighting and also requires an annoying extra step to run all of the code in the notebook.