<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1256">
<meta name="generator" content="Windows Mail 17.5.9600.20315">
<style type="text/css"><!--html { font-family: "Color Emoji", "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; }--></style><style data-externalstyle="true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst,
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle,
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style>
</head>
<body dir="ltr">
<div data-externalstyle="false" dir="ltr" style="font-family: 'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif';font-size:12pt;">
<div>pip install on the current version gives me this:</div>
<div><font size="1">
<p>AssertionError: Missing package data: IPython/html/static/components/backbone/backbone-min.js</p>
--Toby</font><br>
</div>
<div data-signatureblock="true"><br>
</div>
<div style="padding-top: 5px; border-top-color: rgb(229, 229, 229); border-top-width: 1px; border-top-style: solid;">
<div><font face=" 'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif'" style="line-height: 15pt; letter-spacing: 0.02em; font-family: "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 12pt;"><b>From:</b> <a href="mailto:ipython-dev-request@scipy.org" target="_parent">ipython-dev-request@scipy.org</a><br>
<b>Sent:</b> ýSundayý, ýFebruaryý ý9ý, ý2014 ý10ý:ý06<br>
<b>To:</b> <a href="mailto:ipython-dev@scipy.org" target="_parent">'ipython-dev@scipy.org'</a></font></div>
</div>
<div><br>
</div>
<div dir="">
<div id="readingPaneBodyContent">Send IPython-dev mailing list submissions to<br>
ipython-dev@scipy.org<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
http://mail.scipy.org/mailman/listinfo/ipython-dev<br>
or, via email, send a message with subject or body 'help' to<br>
ipython-dev-request@scipy.org<br>
<br>
You can reach the person managing the list at<br>
ipython-dev-owner@scipy.org<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of IPython-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. notebook display (Toby Burnett)<br>
2. Re: notebook display (Brian Granger)<br>
3. Re: Default values for widgets (Brian Granger)<br>
4. Re: Default values for widgets (St?fan van der Walt)<br>
5. Re: Default values for widgets (Brian Granger)<br>
6. Suggestions for easier understanding (Doug Blank)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sat, 8 Feb 2014 18:35:30 +0000<br>
From: Toby Burnett <tburnett@myuw.net><br>
Subject: [IPython-dev] notebook display<br>
To: "'ipython-dev@scipy.org'" <ipython-dev@scipy.org><br>
Message-ID:<br>
<bef05d3bb0a541edaa0dd8ea17f03b15@BLUPR01MB306.prod.exchangelabs.com><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
There are two status indicators in the v2-dev notebook display that I'd like to enhance:<br>
<br>
<br>
* Kernel Busy indication<br>
<br>
* Edit mode<br>
Both are very important to know, but neither is displayed very prominently; a small bit of text in the upper corner for the former, a rather thin green line for the latter. Since Kernel Busy affects the entire notebook, I'd like a more global indicator, to
make it clear that there is no point to try to execute a cell. (I don't know how many times I've forgotten to quit the debug, then wonder why nothing is happening. Or do a restart, and forget to wait for that text to go away.) Edit mode should be rather easy,
just increase the width.<br>
<br>
So I'd like to experiment with alternatives, by adjusting the css. There is a way, I seem to remember, for a user to customize the relevant css. Could someone point me to the instructions, or suggest changes?<br>
<br>
--Toby Burnett<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: http://mail.scipy.org/pipermail/ipython-dev/attachments/20140208/1b6d4dc9/attachment-0001.html
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sat, 8 Feb 2014 12:25:32 -0800<br>
From: Brian Granger <ellisonbg@gmail.com><br>
Subject: Re: [IPython-dev] notebook display<br>
To: IPython developers list <ipython-dev@scipy.org><br>
Message-ID:<br>
<CAH4pYpSj-5srn+17hxhPT2OzY=n7bSO5NJ0g3heNYvc5Oph-og@mail.gmail.com><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
We have added new global kernel and edit/command mode indicators in a<br>
recent pull request - just today. Can you pull the latest and let us<br>
know what you think?<br>
<br>
Cheers,<br>
<br>
Brian<br>
<br>
On Sat, Feb 8, 2014 at 10:35 AM, Toby Burnett <tburnett@myuw.net> wrote:<br>
> There are two status indicators in the v2-dev notebook display that I'd like<br>
> to enhance:<br>
><br>
><br>
><br>
> ? Kernel Busy indication<br>
><br>
> ? Edit mode<br>
><br>
> Both are very important to know, but neither is displayed very prominently;<br>
> a small bit of text in the upper corner for the former, a rather thin green<br>
> line for the latter. Since Kernel Busy affects the entire notebook, I'd like<br>
> a more global indicator, to make it clear that there is no point to try to<br>
> execute a cell. (I don't know how many times I've forgotten to quit the<br>
> debug, then wonder why nothing is happening. Or do a restart, and forget to<br>
> wait for that text to go away.) Edit mode should be rather easy, just<br>
> increase the width.<br>
><br>
><br>
><br>
> So I'd like to experiment with alternatives, by adjusting the css. There is<br>
> a way, I seem to remember, for a user to customize the relevant css. Could<br>
> someone point me to the instructions, or suggest changes?<br>
><br>
><br>
><br>
> --Toby Burnett<br>
><br>
><br>
> _______________________________________________<br>
> IPython-dev mailing list<br>
> IPython-dev@scipy.org<br>
> http://mail.scipy.org/mailman/listinfo/ipython-dev<br>
><br>
<br>
<br>
<br>
-- <br>
Brian E. Granger<br>
Cal Poly State University, San Luis Obispo<br>
bgranger@calpoly.edu and ellisonbg@gmail.com<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Sat, 8 Feb 2014 14:20:32 -0800<br>
From: Brian Granger <ellisonbg@gmail.com><br>
Subject: Re: [IPython-dev] Default values for widgets<br>
To: IPython developers list <ipython-dev@scipy.org><br>
Message-ID:<br>
<CAH4pYpSBEZURnCLne6WE3u-MDn_2vBCa1NvByh9H37NK9aMEfQ@mail.gmail.com><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Thinking a bit more...<br>
<br>
Right now, we look at the following places for widget abbreviations:<br>
<br>
1. kwargs to interact<br>
2. annotations<br>
3. defaults to individual keyword args in the def of the function.<br>
<br>
I think it is a bit dangerous to do 3. It would probably be a better<br>
solution to use 3 for setting the initial value of the widget.<br>
Otherwise, I think we are making defaults for functions do too many<br>
things. Stefan, want to open an issue on this? If others like it, you<br>
could even to a PR ;-) It shouldn't be too difficult.<br>
<br>
Cheers,<br>
<br>
Brian<br>
<br>
On Fri, Feb 7, 2014 at 11:08 PM, St?fan van der Walt <stefan@sun.ac.za> wrote:<br>
> On Fri, 07 Feb 2014 22:56:36 -0800, Brian Granger wrote:<br>
>> interact(f, a=FloatSliderWidget(..., value=10), ...)<br>
><br>
> That will do the trick for me, thanks.<br>
><br>
>> We decided that we wanted to keep the abbreviations as simple as<br>
>> possible and just allow people to pass Widgets for the more<br>
>> complicated usage cases. Part of this is that we are wanting to be as<br>
>> slow/conservative as possible in introducing complexity to new APIs.<br>
>> We want to see how this stuff works in practice and gather data from<br>
>> our users (like this!).<br>
><br>
> The data point for me then is that it feels unintuitive that the default<br>
> keyword argument is not respected.<br>
><br>
> Thanks for all your hard work on this!<br>
><br>
> St?fan<br>
><br>
> _______________________________________________<br>
> IPython-dev mailing list<br>
> IPython-dev@scipy.org<br>
> http://mail.scipy.org/mailman/listinfo/ipython-dev<br>
<br>
<br>
<br>
-- <br>
Brian E. Granger<br>
Cal Poly State University, San Luis Obispo<br>
bgranger@calpoly.edu and ellisonbg@gmail.com<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Sun, 9 Feb 2014 00:47:25 +0200<br>
From: St?fan van der Walt <stefan@sun.ac.za><br>
Subject: Re: [IPython-dev] Default values for widgets<br>
To: IPython developers list <ipython-dev@scipy.org><br>
Message-ID: <20140208224725.GE20211@gmail.com><br>
Content-Type: text/plain; charset=iso-8859-1<br>
<br>
On Sat, 08 Feb 2014 14:20:32 -0800, Brian Granger wrote:<br>
> Right now, we look at the following places for widget abbreviations:<br>
> <br>
> 1. kwargs to interact<br>
> 2. annotations<br>
> 3. defaults to individual keyword args in the def of the function.<br>
<br>
I can certainly add a PR to set the default widget value from the keyword.<br>
Another question: how do you prevent a keyword argument from being turned into<br>
a widget? Currently all arguments are processed, irrespective of whether they<br>
are specified in "interactive".<br>
<br>
St?fan<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Sat, 8 Feb 2014 14:56:40 -0800<br>
From: Brian Granger <ellisonbg@gmail.com><br>
Subject: Re: [IPython-dev] Default values for widgets<br>
To: IPython developers list <ipython-dev@scipy.org><br>
Message-ID:<br>
<CAH4pYpTPhdcZcBE7Od_r-bxxbva7d=0a+i+qsoZTOf4QVtVAkQ@mail.gmail.com><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
This function:<br>
<br>
https://github.com/ipython/ipython/blob/master/IPython/html/widgets/interaction.py#L121<br>
<br>
has two branches where it tests for:<br>
<br>
elif default is not empty:<br>
<br>
Just remove those. Then you would need to add logic *after* the<br>
actual widgets that does something like:<br>
<br>
widget.value = default<br>
<br>
To set the value to the default. The only difficulty is for something<br>
like a slider widget with finite step sizes, we would have to think<br>
about what to do if the value wasn't at a valid step:<br>
<br>
(0, 100, 10) with a default of 33<br>
<br>
We could just allow it , or we could raise a ValueError.<br>
<br>
On Sat, Feb 8, 2014 at 2:47 PM, St?fan van der Walt <stefan@sun.ac.za> wrote:<br>
> On Sat, 08 Feb 2014 14:20:32 -0800, Brian Granger wrote:<br>
>> Right now, we look at the following places for widget abbreviations:<br>
>><br>
>> 1. kwargs to interact<br>
>> 2. annotations<br>
>> 3. defaults to individual keyword args in the def of the function.<br>
><br>
> I can certainly add a PR to set the default widget value from the keyword.<br>
> Another question: how do you prevent a keyword argument from being turned into<br>
> a widget? Currently all arguments are processed, irrespective of whether they<br>
> are specified in "interactive".<br>
><br>
> St?fan<br>
><br>
> _______________________________________________<br>
> IPython-dev mailing list<br>
> IPython-dev@scipy.org<br>
> http://mail.scipy.org/mailman/listinfo/ipython-dev<br>
<br>
<br>
<br>
-- <br>
Brian E. Granger<br>
Cal Poly State University, San Luis Obispo<br>
bgranger@calpoly.edu and ellisonbg@gmail.com<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Sun, 9 Feb 2014 07:59:48 -0500<br>
From: Doug Blank <doug.blank@gmail.com><br>
Subject: [IPython-dev] Suggestions for easier understanding<br>
To: IPython developers list <ipython-dev@scipy.org><br>
Message-ID:<br>
<CAAusYCji-6AYQiHCxYkf95ty4ivzaJqq-5CpcSKA9JyDt4Nvxw@mail.gmail.com><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Devs,<br>
<br>
In looking over the new example notebooks (which are great to learn the new<br>
features), I see a couple of places that could use a little polish to make<br>
them easier to understand, especially for those that aren't expert<br>
programmers. For example, taking a look at:<br>
<br>
http://nbviewer.ipython.org/github/ipython/ipython/blob/master/examples/widgets/Part%202%20-%20Events.ipynb<br>
<br>
it would be easy to change:<br>
<br>
print(widgets.Widget.on_trait_change.__doc__)<br>
<br>
to:<br>
<br>
help(widgets.Widget.on_trait_change)<br>
<br>
which actually looks better, is more informative (even for experts), and<br>
hides unnecessary implementation details. Another suggestion is to consider<br>
hiding the implementational "trait" details. One could use the interface by<br>
just thinking in terms of standard Python terms, such as "attribute" or<br>
"value". For example, the code:<br>
<br>
"""<br>
def on_value_change(name, value):<br>
print(value)<br>
int_range.on_trait_change(on_value_change, 'value')<br>
"""<br>
<br>
might be easier to understand if it were:<br>
<br>
"""<br>
def callback(name, new_value):<br>
print(name, "changed to", new_value)<br>
int_range.on_value_change(callback, 'value')<br>
"""<br>
<br>
Another reason to consider using the method name "on_value_change" rather<br>
than "on_trait_change" is that I'm replicating this API for a different<br>
kernel, and the implementation doesn't use "traitlets". Doesn't seem<br>
necessary to have this implementational detail show in the UI.<br>
<br>
What do you think?<br>
<br>
-Doug<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: http://mail.scipy.org/pipermail/ipython-dev/attachments/20140209/d9fa1804/attachment-0001.html
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
IPython-dev mailing list<br>
IPython-dev@scipy.org<br>
http://mail.scipy.org/mailman/listinfo/ipython-dev<br>
<br>
<br>
End of IPython-dev Digest, Vol 121, Issue 11<br>
********************************************<br>
</div>
</div>
</div>
</body>
</html>