[IPython-dev] notebook display

Toby Burnett tburnett@myuw....
Sun Feb 9 12:37:09 CST 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@scipy.org<mailto:ipython-dev-request@scipy.org>
Sent: ‎Sunday‎, ‎February‎ ‎9‎, ‎2014 ‎10‎:‎06
To: 'ipython-dev@scipy.org'<mailto:ipython-dev@scipy.org>

Send IPython-dev mailing list submissions to
 ipython-dev@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@scipy.org

You can reach the person managing the list at
 ipython-dev-owner@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@myuw.net>
Subject: [IPython-dev] notebook display
To: "'ipython-dev@scipy.org'" <ipython-dev@scipy.org>
Message-ID:
 <bef05d3bb0a541edaa0dd8ea17f03b15@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@gmail.com>
Subject: Re: [IPython-dev] notebook display
To: IPython developers list <ipython-dev@scipy.org>
Message-ID:
 <CAH4pYpSj-5srn+17hxhPT2OzY=n7bSO5NJ0g3heNYvc5Oph-og@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@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@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



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


------------------------------

Message: 3
Date: Sat, 8 Feb 2014 14:20:32 -0800
From: Brian Granger <ellisonbg@gmail.com>
Subject: Re: [IPython-dev] Default values for widgets
To: IPython developers list <ipython-dev@scipy.org>
Message-ID:
 <CAH4pYpSBEZURnCLne6WE3u-MDn_2vBCa1NvByh9H37NK9aMEfQ@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@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@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


------------------------------

Message: 4
Date: Sun, 9 Feb 2014 00:47:25 +0200
From: St?fan van der Walt <stefan@sun.ac.za>
Subject: Re: [IPython-dev] Default values for widgets
To: IPython developers list <ipython-dev@scipy.org>
Message-ID: <20140208224725.GE20211@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@gmail.com>
Subject: Re: [IPython-dev] Default values for widgets
To: IPython developers list <ipython-dev@scipy.org>
Message-ID:
 <CAH4pYpTPhdcZcBE7Od_r-bxxbva7d=0a+i+qsoZTOf4QVtVAkQ@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@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@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



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


------------------------------

Message: 6
Date: Sun, 9 Feb 2014 07:59:48 -0500
From: Doug Blank <doug.blank@gmail.com>
Subject: [IPython-dev] Suggestions for easier understanding
To: IPython developers list <ipython-dev@scipy.org>
Message-ID:
 <CAAusYCji-6AYQiHCxYkf95ty4ivzaJqq-5CpcSKA9JyDt4Nvxw@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@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.scipy.org/pipermail/ipython-dev/attachments/20140209/3b02ee63/attachment-0001.html 


More information about the IPython-dev mailing list