You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Something I'm acutely aware of when talking about this book or running Software Carpentry workshops is that people love working in Jupyter notebooks, but my teaching is constantly steering them away from notebooks (i.e. I effectively tell learners that notebooks are great for prototyping but they should ultimately take the code they've developed in notebooks and incorporate it into a command line script using argparse etc).
There are now tools out there for running notebooks from the command line with different input parameters (papermill), for visualising notebook diffs (ReviewNB) and for building and publishing Python packages from notebooks (nbdev).
An interesting exercise would be to re-do the Zipfs Law analysis and packaging/release in a notebook native fashion, which would essentially mean replacing our content on argparse with papermill, adding ReviewNB to the git content and replacing our packaging content (i.e. setuptools, sphinx, readthedocs) with nbdev. As far as I can tell (I haven't used papermill or nbdev in depth yet), by using these tools it would be possible to define a notebook native workflow (for the Python coding - we'd still be using the command line and make for workflow automation) that doesn't betray any of the best practices we teach.
Thoughts?
The text was updated successfully, but these errors were encountered:
Something I'm acutely aware of when talking about this book or running Software Carpentry workshops is that people love working in Jupyter notebooks, but my teaching is constantly steering them away from notebooks (i.e. I effectively tell learners that notebooks are great for prototyping but they should ultimately take the code they've developed in notebooks and incorporate it into a command line script using
argparse
etc).There are now tools out there for running notebooks from the command line with different input parameters (papermill), for visualising notebook diffs (ReviewNB) and for building and publishing Python packages from notebooks (nbdev).
An interesting exercise would be to re-do the Zipfs Law analysis and packaging/release in a notebook native fashion, which would essentially mean replacing our content on argparse with papermill, adding ReviewNB to the git content and replacing our packaging content (i.e. setuptools, sphinx, readthedocs) with nbdev. As far as I can tell (I haven't used papermill or nbdev in depth yet), by using these tools it would be possible to define a notebook native workflow (for the Python coding - we'd still be using the command line and make for workflow automation) that doesn't betray any of the best practices we teach.
Thoughts?
The text was updated successfully, but these errors were encountered: