[IPython-dev] IPython nosetests extension

[Brian Granger]

>> Hi, this is really exciting and will be a huge improvement for using
>> the notebook for real work.  I will try to look a bit more at this
>> over the next week (in the middle of finals right now).  But a few
>> comments:
>>
>> * Why exactly do you need cell ids?
>
>
> 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?

>>
>> * We are soon going to completely remove the ability to publish
>> javascript from Python.  There are two many horrific security
>> problems.  The replacement abstraction is "javascript plugins" that
>> are under review here:
>>
>> https://github.com/ipython/ipython/pull/2518
>>
>> There is more work to do on this, but this will give you an idea of
>> where we are headed.  Please ask questions about the plugins on that
>> PR.
>
>
> That makes a lot of sense. From a quick reading of it, an extension would be
> able to register JS to be loaded onto the page, and the publish_json method
> would allow the payload to be handed to one of those custom functions.
> There's no reason I can't port this extension to that style once that lands.

Yep it shouldn't be too difficult.

> 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.

> 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.

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.

> 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...

Cheers,

Brian

> Thanks!
>
>
>> Cheers,
>>
>> Brian
>>
>> On Tue, Nov 27, 2012 at 11:49 AM, Taavi Burns <taavi.burns at gmail.com>
>> wrote:
>> > https://github.com/taavi/ipython_nose
>> >
>> > I've gotten the %nose magic Greg Ward and I worked on at the PyCon
>> > Canada
>> > sprints to a reasonable point. I'm not yet convinced that it's ready for
>> > integration into IPython (I think I'd like to get IPython to add id
>> > attributes on the cells so I don't have to add them myself with JS), but
>> > it
>> > should be good enough for some real-world testing.
>> >
>> > It's pip-installable in development mode:
>> > . YOUR/VIRTUALENV/activate
>> > git clone https://github.com/taavi/ipython_nose.git
>> > cd ipython_nose
>> > pip install -e .
>> >
>> > I might not bother putting it on PyPI if it's as likely to get included
>> > in
>> > the base IPython as Fernando was suggesting. ;)
>> >
>> > I'd appreciate any feedback on features and bugs. Feel free to lodge
>> > them in
>> > the github tracker. Pull requests are also welcome! Please keep in mind
>> > that
>> > the end goal is to integrate it into IPython proper, so some work might
>> > be
>> > deferred until then.
>> >
>> > Thanks!
>> >
>> > --
>> > taa
>> > /*eof*/
>> >
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
>
> --
> taa
> /*eof*/
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com