[IPython-dev] IPython nosetests extension
Fri Dec 7 04:40:37 CST 2012
Just wanted to chip in and say this idea is very cool. I don't have any
good ideas/thoughts on the implementation, but I am happy to alpha test
when you have a sample notebook ready to try out.
On Fri, Dec 7, 2012 at 6:27 AM, Brian Granger <firstname.lastname@example.org> wrote:
> >> 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
> > 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
> >> 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
> > 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
> 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
> > 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
> > 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.
> > 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
> > 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
> > 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...
> > Thanks!
> >> Cheers,
> >> Brian
> >> On Tue, Nov 27, 2012 at 11:49 AM, Taavi Burns <email@example.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
> >> > 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),
> >> > 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
> >> > 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
> >> > that
> >> > the end goal is to integrate it into IPython proper, so some work
> >> > be
> >> > deferred until then.
> >> >
> >> > Thanks!
> >> >
> >> > --
> >> > taa
> >> > /*eof*/
> >> >
> >> > _______________________________________________
> >> > IPython-dev mailing list
> >> > IPythonfirstname.lastname@example.org
> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >
> >> --
> >> Brian E. Granger
> >> Cal Poly State University, San Luis Obispo
> >> email@example.com and firstname.lastname@example.org
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPythonemail@example.com
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> > --
> > taa
> > /*eof*/
> > _______________________________________________
> > IPython-dev mailing list
> > IPythonfirstname.lastname@example.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> email@example.com and firstname.lastname@example.org
> IPython-dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev