Difference between revisions of "IPython Comments"

From IPRE Wiki
Jump to: navigation, search
(Miscellaneous Ideas)
(Miscellaneous Ideas)
 
Line 70: Line 70:
 
* can we provide grading assistance for notebooks that are turned in? Perhaps having comments for cells (like github's comments for lines)
 
* can we provide grading assistance for notebooks that are turned in? Perhaps having comments for cells (like github's comments for lines)
 
* Calico provides stepping information; could that be supplied to the notebook for code-in-cell highlighting? would need to identify which cell it came from, and if that cell has changed since the code was evaluated
 
* Calico provides stepping information; could that be supplied to the notebook for code-in-cell highlighting? would need to identify which cell it came from, and if that cell has changed since the code was evaluated
 +
* use the IPython framework for formative exit-slip, clicker-style group behavior assessment. Class answers a multiple choice question; if all (or most) are correct they move on, else they work some more

Latest revision as of 22:59, 28 January 2014

This page notes some issues and wishes that we have regarding IPython.

Hierarchical Kernels

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

Frontend/Backend Negotiations

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.

Notebook Server

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.

IPython Names

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!

Miscellaneous Ideas

  • 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)
  • can we provide grading assistance for notebooks that are turned in? Perhaps having comments for cells (like github's comments for lines)
  • Calico provides stepping information; could that be supplied to the notebook for code-in-cell highlighting? would need to identify which cell it came from, and if that cell has changed since the code was evaluated
  • use the IPython framework for formative exit-slip, clicker-style group behavior assessment. Class answers a multiple choice question; if all (or most) are correct they move on, else they work some more