[IPython-dev] IPython nosetests extension

Taavi Burns taavi.burns at gmail.com
Tue Dec 18 00:58:57 EST 2012

On Fri, Dec 7, 2012 at 1:27 AM, Brian Granger <ellisonbg at gmail.com> wrote:

> > I've enhanced the test failure stack traces such that the function's
> > "filename" (like <ipython-input-DD-HHHHHHHHHHHH>) links to the cell that
> > defines that code. That makes it easy to click close to the definition
> of a
> > failing test or function. Even better would be linking directly to the
> line
> > of code in question… :)  Unfortunately the current implementation has a
> > visual bug when linking to an anchor: the top IPython bar shifts up about
> > 0.3em (it shifts back if you hit the empty fragment, "#").
> Ahh, this is a nice feature.  Can you describe a bit more about how
> you track this information as it flows though the code.  Do the cell
> ids get sent to the kernel?  What does the kernet do with them?

When each cell gets compiled, ipython generates a
(IPython.core.compilerop.code_name, I think) and uses that the
(pseudo-)filename associated with the code object. I don't have to track it
1. The traceback lists the (pseudo-)filename in a pretty recognizeable
way:  re.search(r'ipython-input-(?P<cell_eval_order>\d+)-[0-9a-f]{12}', …)
2. Each cell has the cell_eval_order in square brackets beside it.

All I have to do is link the two. :) The kernel itself doesn't need to know
anything, I'm just taking advantage of the predictability of the HTML
output. One could as easily do all the linkifying in JS instead of
beforehand in the plugin's Python code.

> > I do have a few questions up-front:
> > 1. Is there a better way than peeking at sys.displayhook to determine
> what
> > kind of output to produce?
> I am not quite sure what you mean and how you "peek" and
> sys.displayhook for this.

For now, I stole a page from
https://github.com/catherinedevlin/ipython_doctester with respect to
displaying text/plain when using ipython console vs displaying
text/html+application/javascript in the notebook. But it feels like a
REALLY ugly hack (and requires pyzmq to be installed just for an import to
see that we're NOT using the notebook…).

The particular code is
https://github.com/taavi/ipython_nose/blob/master/ipython_nose.py#L293 .

> > 2. I'd really like to have cell anchor generation happen always. Seems
> like
> > it would be useful to provide intra-notebook links to cells. I'm not sure
> > how one would manage those links as the execution order evolves, though.
> For
> > this extension, that migration is actually a good thing, as the anchor
> > points to the code that was actually run even if it's no longer visible.
> I am trying to understand what the usage cases are.  Would these links
> be typed in by hand by a user?  If so, we would want the ids to have a
> human readable form.  If they are always generated by code they could
> be ugly.

Nope, these are just the automatically-generated links already mentioned
above. They're there just so the user can click on a psuedo-filename and
(hopefully) have the browser scroll to the cell that contained the test
code itself.

> The other thing we have to keep in mind is that we can't ever couple
> the kernel to the notebook frontend.  That is, the kernel can't ever
> know about these cell ids in any formal way.

That makes sense. I'm more interested in the notebook frontend being able
to take advantage of the kernel's existing data, which is sort of the
opposite thing (I think).

> 3. I'd love to have a consistent interface to stream something like stdout
> > character-wise instead of line-wise. Right now it's hacked to hook stdout
> > directly on the console, and with even more horrible jQuery machinations
> on
> > the notebook side.
> Can't you call flush to do this?  Can you describe this a bit more.
> Again, not following how all of this is used.  It sounds messy...

Nope, somehow whenever I try to write a single char for each test, it comes
out on its own line (wrapped in its own pre tag).

Huh. But it looks like if I do this in an ipython notebook cell:
import sys
import time

it works! So there must be something else going on causing the extra tags.
Thanks for pointing out that it OUGHT to work!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20121218/6326195b/attachment.html>

More information about the IPython-dev mailing list