[IPython-dev] How to get the notebook name/path in the kernel?

Konrad Hinsen konrad.hinsen at fastmail.net
Thu Feb 27 04:17:59 EST 2014

Hi Thomas & Fernando,

Thomas Kluyver writes:

 > I don't think there is a good way to get that: the design is
 > specifically that the kernel is an engine to run code, and should
 > not know where that code is coming from.

Fernando Perez writes:

 > Konrad, Matthias' recent description is a great one: it's like
 > asking a book about the color of the eyes of its reader. That
 > question is fundamentally ill-posed, as multiple people may
 > simultaneously read a book.

I see your point view, which is that the notebook is just one way of
interacting with a kernel. Given the I in IPython, that point of view
is understandable.

My point of view is different because my priority is documenting
computations. I see a notebook as a document that describes what was
done and which results were obtained. In the ActivePapers framework, I
need to know where every bit of executed code comes from, because
that's an important element in provenance tracking.

A compromise that is compatible with both points of view is putting
the provenance information for the code in the execute request sent to
the kernel. This could be a notebook name, but also the process id of
a qtconsole. It could be different for each execute request, and
nothing would prevent a single notebook from sending requests to
multiple kernels.

 > In IPython's case, the same applies: a kernel may be attached to a
 > notebook, but simultaneously to a terminal and a qtconsole. While
 > we hold fast on the idea that a notebook should only have *one*
 > kernel, we've even wondered if it could make sense to have multiple
 > notebooks connected to an single kernel (to operate on the same
 > namespace while breaking up the narrative into subdocuments more
 > conveniently).

>From the "documenting a computation" point of view, that would require
some clear link between the notebooks that share a kernel. A link that
remains visible in the resulting notebook files.

 > You can probably write a magic that will call back out from the
 > kernel to the client JS and fetch the notebook path and would store
 > it in a variable in the user namespace, but my JS-fu isn't up to
 > snuff to write that right away. And you'd have to accept that it's
 > a hack with potentially ambiguous results (if for example we later
 > allow multiple notebooks to connect to the same kernel).

It looks like I'll need some hack anyway to proceed. If that hack needs
to be modified in the future, well, that's life on the bleeding edge ;-)

Unfortunately my JS-fu isn't great either, so I'd be grateful for suggestions
from the JS wizards in the audience.


More information about the IPython-dev mailing list