It's best to think of the notebook as a REPL. So you'd want to run `del foo` on the old name.

In fact, this is a good counterexample. Why should the notebook delete the old variable name? What if its value is a thread currently executing?

Notebooks are REPLs, and it's better to get used to that than to try to enforce some confusing time traveling.

But, strangely, Jupyter doesn't also give you a REPL (like, say, R Studio does). I'm always making new cells in the middle to output the column names of my spreadsheet, and then I have to delete them. I used to just always have an ipython REPL running and test things out in there as I write. You can start a ipython instance on the same kernel but I found that messed up my plots when I did that IIRC.

You can get a REPL attached to a notebook in jupyter. When you open a console in jupyter-lab you have the option of attaching it to an already running kernel. Using the notebook interface you can connect a console using `jupyter console --existing`. By default this connects to the most recent session, but you can also specify a session by passing a token.

Yeah, but problems with that are what my last sentence referred to. I didn't try debugging it for long, though.

Just get the extension: https://jupyter-contrib-nbextensions.readthedocs.io/en/lates...

there are quite a few very useful ones, my favourite being collapsible headings: https://jupyter-contrib-nbextensions.readthedocs.io/en/lates...

Yes! I've wanted this too.

Colab has a nice feature that's close to this: Insert -> Scratch code cell

> It's best to think of the notebook as a REPL.

With sections of the history easily replaced.

> So you'd want to run `del foo` on the old name.

And then delete this line, because if you leave it in it'll break when you try and run the file all the way through.

> Notebooks are REPLs, and it's better to get used to that than to try to enforce some confusing time traveling.

Do you mean by treating them as append only and never rerunning any cells?

> In fact, this is a good counterexample. Why should the notebook delete the old variable name? What if its value is a thread currently executing?

The notebook has no idea if it can or can't, but that doesn't mean that leaving it in is good it's simply the only realistic option.

Agree. Get used to the habit of deleting old objects/names when you are replacing them, if you work in notebooks

It's an easy thing to miss though, because you also then need to delete the line of code you used to delete the old object/name so you have no record of cleaning up after yourself.