Creating a widget registry on the Python side. #6493

SylvainCorlay · 2014-09-17T21:21:19Z

Widgets classes are registered on definition of the class using a decorator called register.

@register('custom.Baz')
class Baz(Widget)
    #   ....

When not specifying any argument, the view name is used as a key.

@register()
class Baz(Widget)
    #   ....

The motivation is twofold:
1- Creation of Widgets from the JavaScript side
2- Graphical gui building interface, that needs to know about a registry of widgets.

For the latter case rather than using a registry in the form of a key: widget_class dictionary as now, we could have some other metadata store with it:

key: {
    class: widget_class, 
    metadata: {}
}

The metadata could be used for categorization of widget (control, visualization, container) etc...

SylvainCorlay · 2014-09-17T22:44:43Z

@jdfreder @jasongrout

SylvainCorlay · 2014-09-24T03:30:10Z

Rebased - Now the default key is the fully qualified python class name. Core Jupyter widgets all have custom keys, which are not Python-specific and can be used from the frontend with other backends than Python ones.

SylvainCorlay · 2014-09-25T19:38:41Z

Another possible implementation would be to have something like

+def register(widget):
    """Registers a widget class in the widget registry. 
    The key in the registry is the widget attribute `_backend_name` provided for each core 
    Jupyter widget so that the frontend can use this key regardless of the language of the kernel
    If no backend name is provided, the full class name is used as the key.
    """
    name = widget._backend_name.default_value
    key = name  if name is not None else widget.__module__ + widget.__name__
    Widget.widget_types[key] = widget
    return widget

Then widgets are potentially declared with one more attribute _backend_name.

jdfreder · 2014-09-25T20:01:41Z

IPython/html/widgets/widget_float.py

@@ -43,14 +43,17 @@ def _validate(self, name, old, new):
            self.value = min(max(new, self.min), self.max)


+@register('jupyter.FloatText')


Just out of curiosity, why namespace the Widget names under Jupyter instead of no namespace at all?

Namespaces are one honking great idea -- let's do more of those :)
Just that a name like "Box" is really generic, and should not be reserved in the general namespace.

Gotcha , I agree Jupyter is the right name, since the backend could be arbitrary. @ellisonbg do you think it's okay to introduce the name Jupyter into the IPython repository in this context?

Not yet

On Thu, Sep 25, 2014 at 1:10 PM, Jonathan Frederic <notifications@github.com

wrote:

In IPython/html/widgets/widget_float.py:

@@ -43,14 +43,17 @@ def _validate(self, name, old, new):
self.value = min(max(new, self.min), self.max)

+@register('jupyter.FloatText')

Gotcha , I agree Jupyter is the right name, since the backend could be
arbitrary. @ellisonbg https://github.com/ellisonbg do you think it's
okay to introduce the name Jupyter into the IPython repository in this
context?

—
Reply to this email directly or view it on GitHub
https://github.com/ipython/ipython/pull/6493/files#r18056451.

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

So maybe it's best to either use IPython as the namespace, or no namespace at all.

Ok. What do you prefer between the two proposals? Adding a _backend_name synced attribute or providing it in the decorator?

By 'providing it in the decorator', do you mean hardcoding it into the decorator function? If so, I think just replacing jupyter with ipython would be better.

I meant that besides the discussion on the namespace, I proposed two ways of defining the key for the registry. The first is the one implemented in the PR and the second one is the one proposed in the first comment.

SylvainCorlay · 2014-10-14T03:02:00Z

Renamed the namespace from jupyter to IPython as discusses with @ellisonbg.

jdfreder · 2014-10-14T15:26:09Z

This looks good @SylvainCorlay , I'm 👍 to merge this. Did @ellisonbg look at it in person?

ellisonbg · 2014-10-14T15:31:19Z

No I haven't looked at the code

On Tue, Oct 14, 2014 at 11:26 AM, Jonathan Frederic <
notifications@github.com> wrote:

This looks good @SylvainCorlay https://github.com/SylvainCorlay , I'm [image:
👍] to merge this. Did @ellisonbg https://github.com/ellisonbg look
at it in person?

—
Reply to this email directly or view it on GitHub
#6493 (comment).

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

jdfreder · 2014-10-14T18:13:22Z

@ellisonbg did you want to review this before we merge it? It's related to #6664 - instantiating widgets from Javascript.

ellisonbg · 2014-10-14T18:23:11Z

No don't wait for me on this one, as long as others have looked at it.

On Tue, Oct 14, 2014 at 2:13 PM, Jonathan Frederic <notifications@github.com

wrote:

@ellisonbg https://github.com/ellisonbg did you want to review this
before we merge it? It's related to #6664
#6664 - instantiating widgets
from Javascript.

—
Reply to this email directly or view it on GitHub
#6493 (comment).

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

jdfreder · 2014-10-14T18:25:28Z

@minrk @Carreau or @takluyver care to take a look?

minrk · 2014-10-14T19:35:09Z

I thought part of the goal of using require to load widgets was to remove the need for a widget registry on the javascript side. Do we really want to add one on the Python side, then? Or am I confused about something?

jdfreder · 2014-10-14T19:53:30Z

I don't think you're confused at all- #6664 allows widgets to be instantiated from the front-end without the need for this registry. Instead it uses the Python namespace to load the appropriate widget. Like the Javascript counterpart, the registry would be checked first and then, if not found, the namespace would be checked.

SylvainCorlay · 2014-10-14T21:25:02Z

it is a way to refer to the backend implementation without specifying a language-specific path. (like the current front-end registry does for the js implementation of core widgets)

takluyver · 2014-10-27T23:53:12Z

IPython/html/widgets/widget.py

+    provided for each core IPython widget so that the frontend can use
+    this key regardless of the language of the kernel"""
+    def wrap(widget):
+        l = key if key is not None else widget.__module__ + widget.__name__


The implementation in #6664 will import a module and use the class from that, without needing it in the registry. Assuming we accept that (and I think we should - it nicely parallels loading widgets from require modules in the other direction), is there any use in the @register() decorator without an argument? It registers the class with a name that can be used to find it anyway.

When you pass an argument to the decorator, it gives a name that is independent of the backend language. The R and Julia kernels may have an alternative implementation of the Slider, Text, and all the other core widgets.

Yep, that makes sense - I'm asking what's the use for allowing @register() without specifying a name. You register it as modulename.Classname in that case, but #6664 will let modulename.Classname work with no need to register it, just by using it as an import name.

Gotcha, the other usecase for the registry is to have in one place all the widget classes that were loaded, the goal being to have a (very simple) gui builder.

takluyver · 2014-10-29T19:16:01Z

This needs a rebase, by the way.

SylvainCorlay · 2014-10-30T01:56:14Z

Rebased.

jdfreder · 2014-10-30T22:26:47Z

2- Graphical gui building interface, that needs to know about a registry of widgets.

I thought I had comment somewhere, but I don't see it anymore, that alternatively you could walk the IPython widget namespace instead of registering all of the IPython widgets with the global registry as done here. That way we don't have to add the decorator above every class. @SylvainCorlay @takluyver ?

takluyver · 2014-10-30T22:28:09Z

I'd go with 'explicit is better than implicit' there.

takluyver · 2014-10-30T22:28:55Z

... i.e. I prefer having the widget classes individually registered than having something separate from them that quietly registers them all.

SylvainCorlay · 2014-10-30T22:35:27Z

An advantage of the decorator over walking through the module is that I can use the decorator with other widgets than the core ones, defined in various modules.
Besides, some widgets classes are pure implementation details and one may not want to register them.

jdfreder · 2014-10-30T22:41:14Z

I'd go with 'explicit is better than implicit' there.

No, the thinking was that the core widgets don't need to be registered at all.

One of the arguments against not registering the core widgets was the ability enumerate the widgets. I was just saying we could enumerate through them via the namespace too.

An advantage of the decorator over walking through the module is that I can use the decorator with other widgets than the core ones, defined in various modules.

I wasn't suggesting removing the decorator, just removing the decorate applied to the IPython internal widgets.

Besides, some widgets classes are pure implementation details and one may not want to register them.

True, but one could argue that's a white or black listing (either would work) that should be implemented by whoever is interested in it.

SylvainCorlay · 2014-10-30T22:56:27Z

Wouldn't it be weird to propose a decorator on the one side and to introspect the module in the case of the core widgets? Besides, you would still need to add some class-level information to set the key in the registry.

jdfreder · 2014-10-30T23:06:10Z

Wouldn't it be weird to propose a decorator on the one side and to introspect the module in the case of the core widgets?

I wouldn't worry about that since we wouldn't be implementing the introspection anywhere in IPython itself (a widget builder isn't on the roadmap).

Although, an argument for the registry is the ability for the user to overwrite internal names. I think this helps IPython remain on-the-fly hack friendly, which IMO is Pythonic.

Overall I'm still okay with this being merged as-is. @takluyver do you want to review this anymore (I notice you didn't respond to @SylvainCorlay 's response to your code comment)?

takluyver · 2014-10-30T23:10:48Z

I'm still not convinced that it's useful to put things in the registry if they can be found by import path anyway, but I don't care that much. Merging.

Creating a widget registry on the Python side.

jdfreder · 2014-10-30T23:26:58Z

Thanks @SylvainCorlay !

…stry Creating a widget registry on the Python side.

ivanov added the Needs review label Sep 17, 2014

SylvainCorlay force-pushed the python_widget_registry branch from e8db133 to a5b7a17 Compare September 24, 2014 03:26

SylvainCorlay force-pushed the python_widget_registry branch from a5b7a17 to d31184b Compare September 24, 2014 03:40

jdfreder reviewed Sep 25, 2014
View reviewed changes

SylvainCorlay force-pushed the python_widget_registry branch from d31184b to 9e06034 Compare October 14, 2014 01:45

minrk force-pushed the master branch from 7cc431b to 5416279 Compare October 16, 2014 17:11

takluyver reviewed Oct 27, 2014
View reviewed changes

takluyver added widgets -Waiting for author and removed -Needs review labels Oct 30, 2014

takluyver added this to the 3.0 milestone Oct 30, 2014

SylvainCorlay and others added 4 commits October 29, 2014 21:52

widget registry

291b334

registering core widgets

54c8cd6

Adding custom keys for core jptr notebook

c2de31a

jupyter -> IPython

b46a0ee

SylvainCorlay force-pushed the python_widget_registry branch from 9e06034 to b46a0ee Compare October 30, 2014 01:55

takluyver added -Needs review and removed -Waiting for author labels Oct 30, 2014

jdfreder assigned takluyver Oct 30, 2014

takluyver added a commit that referenced this pull request Oct 30, 2014

Merge pull request #6493 from SylvainCorlay/python_widget_registry

3801ab3

Creating a widget registry on the Python side.

takluyver merged commit 3801ab3 into ipython:master Oct 30, 2014

ivanov removed the -Needs review label Oct 30, 2014

SylvainCorlay deleted the python_widget_registry branch October 30, 2014 23:49

mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014

Merge pull request ipython#6493 from SylvainCorlay/python_widget_regi…

a35a7e6

…stry Creating a widget registry on the Python side.

aggFTW mentioned this pull request Nov 19, 2015

Couldn't add children widget to box when rendering widgets jupyter-widgets/ipywidgets#233

Closed

		@@ -43,14 +43,17 @@ def _validate(self, name, old, new):
		self.value = min(max(new, self.min), self.max)


		@register('jupyter.FloatText')

Creating a widget registry on the Python side. #6493

Creating a widget registry on the Python side. #6493

Conversation

SylvainCorlay commented Sep 17, 2014

SylvainCorlay commented Sep 17, 2014

SylvainCorlay commented Sep 24, 2014

SylvainCorlay commented Sep 25, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SylvainCorlay commented Oct 14, 2014

jdfreder commented Oct 14, 2014

ellisonbg commented Oct 14, 2014

jdfreder commented Oct 14, 2014

ellisonbg commented Oct 14, 2014

jdfreder commented Oct 14, 2014

minrk commented Oct 14, 2014

jdfreder commented Oct 14, 2014

SylvainCorlay commented Oct 14, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

takluyver commented Oct 29, 2014

SylvainCorlay commented Oct 30, 2014

jdfreder commented Oct 30, 2014

takluyver commented Oct 30, 2014

takluyver commented Oct 30, 2014

SylvainCorlay commented Oct 30, 2014

jdfreder commented Oct 30, 2014

SylvainCorlay commented Oct 30, 2014

jdfreder commented Oct 30, 2014

takluyver commented Oct 30, 2014

jdfreder commented Oct 30, 2014