This page notes some issues and wishes that we have regarding IPython.
The %%bash magic is nice, but is apparently implemented in the kernel. It would be nice to not have to replicate this in every new kernel.
- Suggest that there be a hierarchy of kernels so that %%bash could be handled by the topmost, and other commands would get passed to the next kernel if not handled
- Or, perhaps there could be a flat set of kernels that could handle different types, and a router that routes different requests to different kernels
The kernel and the frontend should be able to negotiate certain things:
- The kernel should be able to send information about:
- custom handlers
- custom messages
- The frontends should be able to tell the kernel what mime-types it supports
- only those mime-types would be sent
In general, it would be nice to have the kernel drive some of the startup. It is a pain to have to set config defaults before using a kernel: the kernel could provide those, and they could be saved as they are now if they don't exist.
- kernels could be updated, and could update the config files
- generally need a way for kernels to be more active in the setup process
It would be nice if you could download a new kernel (as a .zip), drop it into a known directory, and then use it without any additional config.
Notebooks should be Kernel Specific
When you startup the notebook frontend, you currently have to specify the kernel. But the kernel isn't used until you open a notebook.
- Suggest that the notebook indicates what kernel (and version) to use
- you could then have different notebooks using different kernels
- kernels could be started when notebook is opened, if not already running
- "ipython notebook" would just start the notebook viewer
- selecting a notebook would indicate what kernel to use
- check to see if it is running, start if not
- could have links to archived, specific versions of ipython and kernel to replicate the notebook over time. At least it should be noted what versions even if those versions aren't available for a link.
You should be able to drop a notebook into a directory, and it would appear in a list of notebooks served (a la nbviewer). This would be an easy way to make a notebook blog.
- should support search across notebooks
- appear in a list, latest first
- create a summary page of the notebook, for viewing in a list
- creates a url to access the page
- should provide easy download for notebook, kernel, and ipython itself for "replicating research"
- allow blog-like functionality: comments, tweets, likes, mark comment as abusive, etc
- optionally, have a kernel running for remote-live edits
- on the fly rendering of notebooks (perhaps with caching)
References and Bibliographies
Need a way to support a bibtex-like system. Sources and citations.
The name "IPython" is nice for referring to the Python kernel, but is too confusing when using IPython without Python. The project should have a name for referring to the glue that connects the fontend (console, qtconsole, notebook) to the backend kernels.
- Suggest having a generic "iconnect", "iglue" or something that starts up frontends and backends
- Suggest that "ipython" be an alias for "iglue --frontend console --backend ipython"
- Is there a generic name for what console, qtconsole, and notebook are?
- "kernel" is not the best name for the backend, because it doesn't relay what it does. But at least it has a name!
- Use notebook for regression testing (run notebook, check output matches given output, and return value is same)
- Use notebook as an automated quiz: don't show output, allow students to enter, and check for match
- instrument log socket communications for educational and learning analysis (what causes students problems, how often do they use help, etc)