Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: make .widget and .widget_types deprecated #3567

Merged

Conversation

maartenbreddels
Copy link
Member

@maartenbreddels maartenbreddels commented Aug 24, 2022

In #3122 we renamed .widget and .widget_types to ._active_widgets
and ._widget_types. That breaks code, and we did not have a deprecation
period.
This PR makes the dict and registry non-members of the Widget class
and puts in a backwards compatible way to deprecated these members.

Closes #3562

In jupyter-widgets#3122 we renamed .widget and .widget_types to ._active_widgets
and ._widget_types. That breaks code, and we did not have a deprecation
period.
This PR makes the dict and registry non-members of the Widget class
and puts in a backwards compatible way the deprecated these members.
@github-actions
Copy link

Binder 👈 Launch a binder notebook on branch maartenbreddels/ipywidgets/fix_widgets_and_widget_types

Copy link
Member

@jasongrout jasongrout left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The two conventions for module-level variables I see in pep8 are:

Global variable names:

(Let’s hope that these variables are meant for use inside one module only.) The conventions are about the same as those for functions.

Modules that are designed for use via from M import * should use the all mechanism to prevent exporting globals, or use the older convention of prefixing such globals with an underscore (which you might want to do to indicate these globals are “module non-public”).

and Constants:

Constants are usually defined on a module level and written in all capital letters with underscores separating words. Examples include MAX_OVERFLOW and TOTAL.

What do you think about making instances either _instances or INSTANCES (and same for registry).

python/ipywidgets/ipywidgets/widgets/widget.py Outdated Show resolved Hide resolved
python/ipywidgets/ipywidgets/widgets/widget.py Outdated Show resolved Hide resolved
@jasongrout jasongrout added this to the 8.0 milestone Aug 26, 2022
maartenbreddels and others added 4 commits August 30, 2022 17:04
Co-authored-by: Jason Grout <jasongrout@users.noreply.github.com>
Co-authored-by: Jason Grout <jasongrout@users.noreply.github.com>
@jasongrout jasongrout modified the milestones: 8.0, 8.0.x Aug 30, 2022
@vidartf
Copy link
Member

vidartf commented Sep 6, 2022

To fully close #3562 I think we should also add a note to the migration guide about this.

@jasongrout
Copy link
Member

@maartenbreddels - I switched the internal imports to relative imports, and added a note to the migration docs like Vidar suggested in maartenbreddels#2 - can you take a look?

@jasongrout jasongrout merged commit 3ce6472 into jupyter-widgets:master Sep 13, 2022
@bollwyvl bollwyvl mentioned this pull request Dec 18, 2022
3 tasks
@bollwyvl
Copy link
Contributor

This introduced a small issue, referring to register.get instead of _registry.get, which breaks creating new widgets in the client.

A prospective fix is up in #3653.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Note in migration guide the privatization of .widgets and .widget_types
4 participants