4 ms·

Yes, absolutely. What you describe is Django's `manage.py shell_plus`, which does not use a notebook. So not to be argumentative, but to be clear about this di

Yes, absolutely. What you describe is Django's `manage.py shell_plus`, which does not use a notebook. So not to be argumentative, but to be clear about this discussion, I'm going to say that your comment is 70% irrelevant, since using an interactive REPL is routine in python development. However, it is 30% relevant, because retrieving and archiving the code you ran is going to be much more convenient in a notebook than by using %history or whatever in a shell-based ipython.

Myrmornis 7y ago
On reflection, I'm not even sure that the notebook is that much of an advantage over shell-based ipython for archiving the commands. One problem is with a notebook, you have less idea what you've actually executed: you just have a bunch of code sitting in cells in a web app. Whereas the shell UX is extremely simple/linear: if a command is in ipython history, then you executed it.
- nnq 7y ago
  yeah, but sometimes you want to execute snippet 12 4 times then using a variable derived from that go back to snippet 8 etc. notebooks are about non-linear execution sure, there's enough rope to hang the whole neighborhood in that, you can totally f things up with no chance of recovery by doing that, or end up with data you have no idea how you got at and no way to re-trace 100% deterministically your steps but if you have some discipline, stick to read-only-wrt-db, and you just delete whole notebook when things stop making any sense, it's... magical to have all that power and freedom at you finger tips, without having to keep much stuff in your working memory since you can dump it in a var or cell anytime, and mix your text notes through the code too! It's not for everyone, but I love this beautiful chaos :)
  - Myrmornis 7y ago
    OK, fair enough! All of which does seem to paint a picture of a programming environment which is handy for ad-hoc interventions and graphical/audio/video/HTML output but highly unsuitable for organized development of a code base (even a small one), highly unsuitable for systematic debugging, and highly unsuitable for beginners learning to program beyond their first baby steps (as @cycomanic points out elsewhere in this discussion).

Myrmornis 7y ago

On reflection, I'm not even sure that the notebook is that much of an advantage over shell-based ipython for archiving the commands. One problem is with a notebook, you have less idea what you've actually executed: you just have a bunch of code sitting in cells in a web app. Whereas the shell UX is extremely simple/linear: if a command is in ipython history, then you executed it.

nnq 7y ago
yeah, but sometimes you want to execute snippet 12 4 times then using a variable derived from that go back to snippet 8 etc. notebooks are about non-linear execution sure, there's enough rope to hang the whole neighborhood in that, you can totally f things up with no chance of recovery by doing that, or end up with data you have no idea how you got at and no way to re-trace 100% deterministically your steps but if you have some discipline, stick to read-only-wrt-db, and you just delete whole notebook when things stop making any sense, it's... magical to have all that power and freedom at you finger tips, without having to keep much stuff in your working memory since you can dump it in a var or cell anytime, and mix your text notes through the code too! It's not for everyone, but I love this beautiful chaos :)
- Myrmornis 7y ago
  OK, fair enough! All of which does seem to paint a picture of a programming environment which is handy for ad-hoc interventions and graphical/audio/video/HTML output but highly unsuitable for organized development of a code base (even a small one), highly unsuitable for systematic debugging, and highly unsuitable for beginners learning to program beyond their first baby steps (as @cycomanic points out elsewhere in this discussion).