Thanks to visit codestin.com
Credit goes to github.com

Skip to content

FIX: be very paranoid about checking what the current canvas is #25573

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

tacaswell
Copy link
Member

PR Summary

closes #25572

There are many ways for things to end up in odd states, the goal here is to detect if the the canvas has changed under us when trying to manage the state of widgets.

PR Checklist

Documentation and Tests

  • Has pytest style unit tests (and pytest passes)
  • [N/A] Documentation is sphinx and numpydoc compliant (the docs should build without error).
  • [N/A] New plotting related features are documented with examples.

Release Notes

  • [N/A] New features are marked with a .. versionadded:: directive in the docstring and documented in doc/users/next_whats_new/
  • [N/A] API changes are marked with a .. versionchanged:: directive in the docstring and documented in doc/api/next_api_changes/
  • [N/A] Release notes conform with instructions in next_whats_new/README.rst or next_api_changes/README.rst

@tacaswell tacaswell added this to the v3.7.2 milestone Mar 29, 2023
@anntzer
Copy link
Contributor

anntzer commented Mar 29, 2023

Perhaps the simpler check would be self.canvas is self.canvas.figure.canvas? Note that while figure.canvas can change (hence the introduction of _changed_canvas), I think canvas.figure does not ever change (at least in practice... it may even be possible to spec that), so the proposed check is effectively "does the figure I initially got still use the same canvas as initially?" Also none of these attributes should ever be None, AFAICT.

Alternatively, we could additionally record self._figure = ax.figure in the constructor and check self._figure.canvas is self.canvas; again this should sidestep the None problems?

@tacaswell
Copy link
Member Author

Alternatively, we could additionally record self._figure = ax.figure in the constructor and check self._figure.canvas is self.canvas; again this should sidestep the None problems?

I think that would still miss the "middle removed" issue as we have references that skip generations and we should avoid adding more hard-references than we strictly need....

But I will change to self.canvas is self.canvas.figure.canvas

@tacaswell tacaswell force-pushed the fix_removed_widget_axes branch from 54db976 to 7100b57 Compare March 31, 2023 20:08
# no canvas, something is very fishy
if self.canvas is None:
return True
return self.canvas is not self.canvas.figure.canvas
Copy link
Contributor

Choose a reason for hiding this comment

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

Can be made one-liner as return self.canvas is not None and self.canvas is not self.canvas.figure.canvas.

Copy link
Contributor

@anntzer anntzer left a comment

Choose a reason for hiding this comment

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

Modulo CI, and with an optional additional comment.

@tacaswell
Copy link
Member Author

Hmm, we are back to not being careful enough...but only an azure?!

@anntzer
Copy link
Contributor

anntzer commented Apr 3, 2023

That's a bit fishy, but perhaps just change all the self.ax.draw_artist(artist) by artist.draw(self.canvas.get_renderer())? (which should bypass the problem of whether self.ax.figure is None or not -- anyways, having draw_artist be an Axes method always seemed a bit weird to me (I do realize that historically we cached the renderer on the axes, but that's not really the logical place to have it)).

@QuLogic QuLogic modified the milestones: v3.7.2, v3.7.3 Jul 5, 2023
@QuLogic QuLogic modified the milestones: v3.7.3, v3.8.0 Sep 9, 2023
@ksunden ksunden removed this from the v3.8.0 milestone Sep 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: Artist.remove() isn't fully removing it from figure
6 participants