[IPython-dev] notebook display
Toby Burnett
tburnett at myuw.net
Sun Feb 9 13:37:09 EST 2014
pip install on the current version gives me this:
AssertionError: Missing package data: IPython/html/static/components/backbone/backbone-min.js
--Toby
From: ipython-dev-request at scipy.org<mailto:ipython-dev-request at scipy.org>
Sent: Sunday, February 9, 2014 10:06
To: 'ipython-dev at scipy.org'<mailto:ipython-dev at scipy.org>
Send IPython-dev mailing list submissions to
ipython-dev at scipy.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.scipy.org/mailman/listinfo/ipython-dev
or, via email, send a message with subject or body 'help' to
ipython-dev-request at scipy.org
You can reach the person managing the list at
ipython-dev-owner at scipy.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of IPython-dev digest..."
Today's Topics:
1. notebook display (Toby Burnett)
2. Re: notebook display (Brian Granger)
3. Re: Default values for widgets (Brian Granger)
4. Re: Default values for widgets (St?fan van der Walt)
5. Re: Default values for widgets (Brian Granger)
6. Suggestions for easier understanding (Doug Blank)
----------------------------------------------------------------------
Message: 1
Date: Sat, 8 Feb 2014 18:35:30 +0000
From: Toby Burnett <tburnett at myuw.net>
Subject: [IPython-dev] notebook display
To: "'ipython-dev at scipy.org'" <ipython-dev at scipy.org>
Message-ID:
<bef05d3bb0a541edaa0dd8ea17f03b15 at BLUPR01MB306.prod.exchangelabs.com>
Content-Type: text/plain; charset="us-ascii"
There are two status indicators in the v2-dev notebook display that I'd like to enhance:
* Kernel Busy indication
* Edit mode
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.
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?
--Toby Burnett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/ipython-dev/attachments/20140208/1b6d4dc9/attachment-0001.html
------------------------------
Message: 2
Date: Sat, 8 Feb 2014 12:25:32 -0800
From: Brian Granger <ellisonbg at gmail.com>
Subject: Re: [IPython-dev] notebook display
To: IPython developers list <ipython-dev at scipy.org>
Message-ID:
<CAH4pYpSj-5srn+17hxhPT2OzY=n7bSO5NJ0g3heNYvc5Oph-og at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
We have added new global kernel and edit/command mode indicators in a
recent pull request - just today. Can you pull the latest and let us
know what you think?
Cheers,
Brian
On Sat, Feb 8, 2014 at 10:35 AM, Toby Burnett <tburnett at myuw.net> wrote:
> There are two status indicators in the v2-dev notebook display that I'd like
> to enhance:
>
>
>
> ? Kernel Busy indication
>
> ? Edit mode
>
> 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.
>
>
>
> 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?
>
>
>
> --Toby Burnett
>
>
> _______________________________________________
> 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
------------------------------
Message: 3
Date: Sat, 8 Feb 2014 14:20:32 -0800
From: Brian Granger <ellisonbg at gmail.com>
Subject: Re: [IPython-dev] Default values for widgets
To: IPython developers list <ipython-dev at scipy.org>
Message-ID:
<CAH4pYpSBEZURnCLne6WE3u-MDn_2vBCa1NvByh9H37NK9aMEfQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Thinking a bit more...
Right now, we look at the following places for widget abbreviations:
1. kwargs to interact
2. annotations
3. defaults to individual keyword args in the def of the function.
I think it is a bit dangerous to do 3. It would probably be a better
solution to use 3 for setting the initial value of the widget.
Otherwise, I think we are making defaults for functions do too many
things. Stefan, want to open an issue on this? If others like it, you
could even to a PR ;-) It shouldn't be too difficult.
Cheers,
Brian
On Fri, Feb 7, 2014 at 11:08 PM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> On Fri, 07 Feb 2014 22:56:36 -0800, Brian Granger wrote:
>> interact(f, a=FloatSliderWidget(..., value=10), ...)
>
> That will do the trick for me, thanks.
>
>> We decided that we wanted to keep the abbreviations as simple as
>> possible and just allow people to pass Widgets for the more
>> complicated usage cases. Part of this is that we are wanting to be as
>> slow/conservative as possible in introducing complexity to new APIs.
>> We want to see how this stuff works in practice and gather data from
>> our users (like this!).
>
> The data point for me then is that it feels unintuitive that the default
> keyword argument is not respected.
>
> Thanks for all your hard work on this!
>
> St?fan
>
> _______________________________________________
> 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
------------------------------
Message: 4
Date: Sun, 9 Feb 2014 00:47:25 +0200
From: St?fan van der Walt <stefan at sun.ac.za>
Subject: Re: [IPython-dev] Default values for widgets
To: IPython developers list <ipython-dev at scipy.org>
Message-ID: <20140208224725.GE20211 at gmail.com>
Content-Type: text/plain; charset=iso-8859-1
On Sat, 08 Feb 2014 14:20:32 -0800, Brian Granger wrote:
> Right now, we look at the following places for widget abbreviations:
>
> 1. kwargs to interact
> 2. annotations
> 3. defaults to individual keyword args in the def of the function.
I can certainly add a PR to set the default widget value from the keyword.
Another question: how do you prevent a keyword argument from being turned into
a widget? Currently all arguments are processed, irrespective of whether they
are specified in "interactive".
St?fan
------------------------------
Message: 5
Date: Sat, 8 Feb 2014 14:56:40 -0800
From: Brian Granger <ellisonbg at gmail.com>
Subject: Re: [IPython-dev] Default values for widgets
To: IPython developers list <ipython-dev at scipy.org>
Message-ID:
<CAH4pYpTPhdcZcBE7Od_r-bxxbva7d=0a+i+qsoZTOf4QVtVAkQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
This function:
https://github.com/ipython/ipython/blob/master/IPython/html/widgets/interaction.py#L121
has two branches where it tests for:
elif default is not empty:
Just remove those. Then you would need to add logic *after* the
actual widgets that does something like:
widget.value = default
To set the value to the default. The only difficulty is for something
like a slider widget with finite step sizes, we would have to think
about what to do if the value wasn't at a valid step:
(0, 100, 10) with a default of 33
We could just allow it , or we could raise a ValueError.
On Sat, Feb 8, 2014 at 2:47 PM, St?fan van der Walt <stefan at sun.ac.za> wrote:
> On Sat, 08 Feb 2014 14:20:32 -0800, Brian Granger wrote:
>> Right now, we look at the following places for widget abbreviations:
>>
>> 1. kwargs to interact
>> 2. annotations
>> 3. defaults to individual keyword args in the def of the function.
>
> I can certainly add a PR to set the default widget value from the keyword.
> Another question: how do you prevent a keyword argument from being turned into
> a widget? Currently all arguments are processed, irrespective of whether they
> are specified in "interactive".
>
> St?fan
>
> _______________________________________________
> 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
------------------------------
Message: 6
Date: Sun, 9 Feb 2014 07:59:48 -0500
From: Doug Blank <doug.blank at gmail.com>
Subject: [IPython-dev] Suggestions for easier understanding
To: IPython developers list <ipython-dev at scipy.org>
Message-ID:
<CAAusYCji-6AYQiHCxYkf95ty4ivzaJqq-5CpcSKA9JyDt4Nvxw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Devs,
In looking over the new example notebooks (which are great to learn the new
features), I see a couple of places that could use a little polish to make
them easier to understand, especially for those that aren't expert
programmers. For example, taking a look at:
http://nbviewer.ipython.org/github/ipython/ipython/blob/master/examples/widgets/Part%202%20-%20Events.ipynb
it would be easy to change:
print(widgets.Widget.on_trait_change.__doc__)
to:
help(widgets.Widget.on_trait_change)
which actually looks better, is more informative (even for experts), and
hides unnecessary implementation details. Another suggestion is to consider
hiding the implementational "trait" details. One could use the interface by
just thinking in terms of standard Python terms, such as "attribute" or
"value". For example, the code:
"""
def on_value_change(name, value):
print(value)
int_range.on_trait_change(on_value_change, 'value')
"""
might be easier to understand if it were:
"""
def callback(name, new_value):
print(name, "changed to", new_value)
int_range.on_value_change(callback, 'value')
"""
Another reason to consider using the method name "on_value_change" rather
than "on_trait_change" is that I'm replicating this API for a different
kernel, and the implementation doesn't use "traitlets". Doesn't seem
necessary to have this implementational detail show in the UI.
What do you think?
-Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/ipython-dev/attachments/20140209/d9fa1804/attachment-0001.html
------------------------------
_______________________________________________
IPython-dev mailing list
IPython-dev at scipy.org
http://mail.scipy.org/mailman/listinfo/ipython-dev
End of IPython-dev Digest, Vol 121, Issue 11
********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20140209/3b02ee63/attachment.html>
More information about the IPython-dev
mailing list