Interact/Interactive for widget #4960
Conversation
|
(reposting comment here---I accidentally put it on the closed PR)
It's been incredibly convenient in Sage to have default arguments in a function control the widgets. It's a really useful shortcut. Something like: def interact_default(f):
args,defaults = inspect.getargspec(f) # pseudo-code here...I don't remember exactly what getargspec returns
return interact(f, zip(args,defaults)) |
|
|
||
| def interact(f, **kwargs): | ||
| w = interactive(f, **kwargs) | ||
| display(w) |
There was a problem hiding this comment.
To match what we'd said, this needs:
f.widget = w
return f
There was a problem hiding this comment.
Plus we need some cleverness in this function to detect whether it's passed a function or whether it's being used as a decorator factory. IPython.external.decorator may be able to help with that.
There was a problem hiding this comment.
Scratch that, I don't think the decorator library is helpful in this case.
|
At present, interact won't work as a decorator. I can work on this after lunch unless you're in the middle of working on it, @ellisonbg . |
|
Here is the plan on I going to pursue:
But I won't be working on the interact stuff until later tonight. If you On Fri, Jan 31, 2014 at 11:57 AM, Thomas Kluyver
Brian E. Granger |
|
A next step after an interact decorator is making it possible to have two interacts in a single cell. If there was a way to contain the output of the interact function to a certain div, then you could have, say, two different interacts in two different tabs, where the output for each function would also be shown in the tab. |
|
Unfortunately that would require refactoring the entire way that output On Fri, Jan 31, 2014 at 2:26 PM, Jason Grout notifications@github.comwrote:
Brian E. Granger |
|
+1 (or really, +a lot). We do it in the cell server by setting output handlers, but I'm not really happy with the way we do it. Hopefully we'll have time soon to rewrite how we direct output. |
|
@jasongrout : with using the default arguments to generate widgets, are there ever situations where you want to prevent that, so there isn't a widget for every argument? I'm just wondering if we should do it by default, and if there should be some way of overriding the default per function or per arg. |
|
We make the assumption that every argument corresponds to a control. You can use By the way, we also allow some extra parameters to the interact decorator, like |
|
Ok I have implemented support for I have also added an Next task is to create the different decorator syntaxes for |
|
I have created a new |
|
Apologies if this isn't relevant, but I just tried this branch out and found that typing into a text widget clashed with the modal keys, i.e., I couldn't type 'i' or 's' or any other action key. |
|
We are in the process of fixing these various bugs. I would keep pulling On Tue, Feb 4, 2014 at 7:10 AM, Alistair Miles notifications@github.comwrote:
Brian E. Granger |
|
Thanks Brian. I should be pulling from ellisonbg:newinteract right? I'm on On Tue, Feb 4, 2014 at 5:18 PM, Brian E. Granger
Alistair Miles |
|
OK, then we probably haven't rebased that branch since the bugs were fixed. On Tue, Feb 4, 2014 at 9:22 AM, Alistair Miles notifications@github.comwrote:
Brian E. Granger |
|
@minrk here is a notebook with different interact calls for different function arguments: |
|
excellent, thanks |
|
Also we should set |
Also, preserve the order of function parameters from the signature where possible. This uses a backport of the Python 3.3 signature machinery that @minrk found and improved.
This involves a bunch of really complicated logic to handle the different ways that function parameters can be processed in Python. Most importantly, this includes support for *args in interact.
- use %matplotlib, not %pylab - use non-identical graph generators in networks example
fixes unhanded case where only one entry is a float
|
Should have pretty good test coverage of the abbreviations and different call forms now. I just read through the file, and added a test or two for every abbreviation form I could find, including values coming from default values, annotations, and kwargs passed to interact. Various bugs found and fixed while writing the tests. I also added |
|
Yes, I think On Thu, Feb 6, 2014 at 5:14 PM, Min RK notifications@github.com wrote:
Brian E. Granger |
|
If we're making readout=True the default, then (eventually) I think we should support setting the value via the readout. It's really natural to use the slider if you have a rough idea, but then try to change the number if you want to examine a specific case. It works particularly well with float ranges, since the slider will not hit all floating point numbers in the range. |
|
@jasongrout that makes sense, eventually. |
|
readout=True is now the default on all sliders, so I removed the redundant assignment in interact. |
|
What's left for this PR? |
|
I'd like to take a deeper look at it, but won't have time until next week, likely. I suppose any comments I have could be made after it's merged too, of course. |
after recent API changes
|
Absolutely, we will probably be iterating on this one for the next few months, so no problem continuing discussion after a first pass has been merged. |
|
Great work on this @minrk and @takluyver ! Merging ! |
Interact/Interactive for widget
|
I hope the "next few months" comment doesn't mean that 2.0 will be delayed that long! |
|
Not at all, I think we are getting pretty close. I mean that cutting 2.0 doesn't mean we stop finding things to improve here. |
Interact/Interactive for widget
This is a first official go at implementing interact/interactive on top of IPython's widgets. Closes #4883