3 ms·

This runs Jupyter in the background. So it retains some of the issues with it - e.g. notebook diff,etc.

mattnewton 8y ago
It actually looks like it is creating the notebook format on the fly from user’s selections, so it probably doesn’t suffer the notebook json diff problem. Other issues you have though, probably are present.
- pavanagrawal123 8y ago
  any exported notebook will suffer from the same issue, but the source file is just a normal python file, so diffs will be fine for those
thanatropism 8y ago
I think (and this isn't just personal experience) most of the appeal of Jupyter is the fractioned persistent state that allows you to write incrementally but not re-run increasingly long scripts. Inline plots are just gravy. (Yes yes write documents export LaTeX. Not sure people care about this at all) I've been developing a style where development "cells" are cached with joblib.Memory so re-running a script from command line doesn't take idiotic amounts of time. Further, I have litte context managers such that with Figure('filename.png'): plotting_logic() exports a file that immediately shows in the folder navigation bar of Atom. It's overall a better experience. What I would really like is being able to use joblib.Memory not as a decorator (which requires bunching up your "cells" in functions and calling them separately) but as a context manager. --- To the tune of the "Portlandia" song: the dream of MUMPS state is alive in joblib...
- mirashii 8y ago
  You can actually do this as a context manager, I have done something very similar in the past. I created a dummy context manager with a unique name and used an importhook to do an AST rewrite to the body of the context manager. It's a bit of a hack (okay, a lot of a hack), but allows for some really neat patterns that context managers didn't allow.
geekraver 8y ago
You're confusing the Jupyter backend (which manages the Python kernels) with the front-end (which maintains the JSON document that reflects the notebook). You can have different front ends that use different formats than .ipynb.

It actually looks like it is creating the notebook format on the fly from user’s selections, so it probably doesn’t suffer the notebook json diff problem. Other issues you have though, probably are present.

pavanagrawal123 8y ago
any exported notebook will suffer from the same issue, but the source file is just a normal python file, so diffs will be fine for those

thanatropism 8y ago

I think (and this isn't just personal experience) most of the appeal of Jupyter is the fractioned persistent state that allows you to write incrementally but not re-run increasingly long scripts. Inline plots are just gravy. (Yes yes write documents export LaTeX. Not sure people care about this at all) I've been developing a style where development "cells" are cached with joblib.Memory so re-running a script from command line doesn't take idiotic amounts of time. Further, I have litte context managers such that with Figure('filename.png'): plotting_logic() exports a file that immediately shows in the folder navigation bar of Atom. It's overall a better experience. What I would really like is being able to use joblib.Memory not as a decorator (which requires bunching up your "cells" in functions and calling them separately) but as a context manager. --- To the tune of the "Portlandia" song: the dream of MUMPS state is alive in joblib...

mirashii 8y ago
You can actually do this as a context manager, I have done something very similar in the past. I created a dummy context manager with a unique name and used an importhook to do an AST rewrite to the body of the context manager. It's a bit of a hack (okay, a lot of a hack), but allows for some really neat patterns that context managers didn't allow.

geekraver 8y ago

You're confusing the Jupyter backend (which manages the Python kernels) with the front-end (which maintains the JSON document that reflects the notebook). You can have different front ends that use different formats than .ipynb.