Nah, this is working backwards. I've seen this dynamic plenty of times before: someone gets comfortable with some workflow in a limited context, and try to force into larger, more sophisticated context where it doesn't work as well rather than accepting that there are better tools for the job.
Nothing wrong with putting this stuff out there I guess, but if anybody I was working with was doing anything like this, we'd be scheduling a few sit-downs where I explain the proper way of handling this stuff and spare them the headaches of trying to fit a square peg into a round hole.
Thanks! I wanted to drop the dependency on .ipynb for this version, so I went with .py files instead. The detachable kernel itself isn't tied to .py, so I'm considering a dedicated extension like .pynb (Python notebook) to distinguish notebooks from regular Python scripts in the future.
Nah, this is working backwards. I've seen this dynamic plenty of times before: someone gets comfortable with some workflow in a limited context, and try to force into larger, more sophisticated context where it doesn't work as well rather than accepting that there are better tools for the job.
Nothing wrong with putting this stuff out there I guess, but if anybody I was working with was doing anything like this, we'd be scheduling a few sit-downs where I explain the proper way of handling this stuff and spare them the headaches of trying to fit a square peg into a round hole.
This is really really useful and something I've been looking to build in the roadmap for my notebook IDE (https://trykrypton.com/)
Any reason why you also decided to go with .py files as part of your detachable kernel architecture?
Thanks! I wanted to drop the dependency on .ipynb for this version, so I went with .py files instead. The detachable kernel itself isn't tied to .py, so I'm considering a dedicated extension like .pynb (Python notebook) to distinguish notebooks from regular Python scripts in the future.