I think the article's point is that you don't restart script.py again and again but start it once, then modify it while it's running, and once you are happy wit

I think the article's point is that you don't restart script.py again and again but start it once, then modify it while it's running, and once you are happy with the final debugged version, the script.py program saved on your hard disk is that final debugged version. You can sort of do something like this with REPLs, by copying code around between an editor window and a REPL window until you are satisfied that it's what you want. But you have to keep the REPL and the editor in sync manually. For example, if by experimenting in the REPL or debugger you find a bug that requires changes to three functions, you must either change them in the editor and copy all off the changes to the REPL to test the new program state; or you can redefined them in the REPL's less-than-ideal editor and then make sure to copy the updated versions to the real editor to save them in the source file. I've worked with a few systems that were not REPL-based but more notebook-based, and it's very cool if the system keeps track of stuff for you. In particular, Coq and Isabelle have such environments. (I've never worked with Jupyter, but I think I should give it a try.)