Skip to content

Mnt/no reset axes#24626

Closed
tacaswell wants to merge 2 commits into
matplotlib:mainfrom
tacaswell:mnt/no_reset_axes
Closed

Mnt/no reset axes#24626
tacaswell wants to merge 2 commits into
matplotlib:mainfrom
tacaswell:mnt/no_reset_axes

Conversation

@tacaswell
Copy link
Copy Markdown
Member

PR Summary

This makes our Artists very picky about being re-added to Axes / Figures once they have been removed. Currently there is enough checking in place that it should not be possible to try and add the Artist to more than one simultaneously, but it is not clear we actually do enough clean up to make these re-added Aritsts actually work. I suspect in most cases where users are removing / readding Aritsts they would be better off using set_visible(), but I have no idea how common it actually is.

Open questions:

  • should this actually start a deprecation cycle where we warn about "going through None" on Artists?
  • should this wait for the ArtistList deprecation to expire (if we are ever going to expire those)?

I think this is sufficiently tested, but needs API change notes, but waiting for the above decisions before writing them.

In any case, the change to the OffsetBox test should probably be pulled out and if we do not take this, find a way to make that error out for maybe other reasons.

PR Checklist

Documentation and Tests

  • Has pytest style unit tests (and pytest passes)
  • Documentation is sphinx and numpydoc compliant (the docs should build without error).

Release Notes

  • API changes are marked with a .. versionchanged:: directive in the docstring and documented in doc/api/next_api_changes/

@tacaswell tacaswell added this to the v3.7.0 milestone Dec 4, 2022
@tacaswell tacaswell marked this pull request as draft December 5, 2022 00:11
@tacaswell tacaswell modified the milestones: v3.7.0, v3.8.0 Dec 15, 2022
@tacaswell
Copy link
Copy Markdown
Member Author

On consideration, this has sat for so long it can sit a bit longer. We have more than enough to try and get in for 3.7 so defer this to 3.8.

@sryu1
Copy link
Copy Markdown

sryu1 commented Mar 16, 2023

Does this mean ArtistList does not work anymore? It seems like starting from 3.7.0, pop() function doesn't work on it...

@QuLogic
Copy link
Copy Markdown
Member

QuLogic commented Mar 16, 2023

@sryu1
Copy link
Copy Markdown

sryu1 commented Mar 16, 2023

Ah ok, thank you.

tacaswell added 2 commits May 22, 2026 17:43
This is exactly the sort of error that this check is supposed to catch.
@timhoffm
Copy link
Copy Markdown
Member

timhoffm commented May 23, 2026

Is this really necessary? I could imagine a use case where one has a GUI with multiple Axes and functionality to move datasets across Axes. That would be significantly more complicated if one had to read all properties from an Artist and create a new one with the same properties.

IMHO „ but it is not clear we actually do enough clean up to make these re-added Aritsts actually work.“ is not enough justification for prohibiting. It rather shows that our architecture is not clear. Overall, I suppose Artists hold little Axes-specific information, and I don’t see a fundamental blocker why we shouldn’t be able to systematically separate that. I‘d rather go with „re-adding is permitted but not well-tested behavior.“ and handle issues when they arise, either by fixing or by prohibiting re-use of specific Artists, when there are good reasons for it.

@tacaswell
Copy link
Copy Markdown
Member Author

I‘d rather go with „re-adding is permitted but not well-tested behavior.“ and handle issues when they arise, either by fixing or by prohibiting re-use of specific Artists, when there are good reasons for it.

ok, I'm sold on that. I've been dragging this PR along for a while now without thinking through why to begin with 🐑 . I think three things have changed in the last few years:

  1. we did deprecate settable ArtistList so artists only get added through a path where we can update their state (which eliminates a set of issues where the artist has transforms from the wrong axis)
  2. we have gotten much better about breaking the loops on remove (driven by helping gc not need to wait for the cyclic passes to release memory)
  3. some of the work with @ksunden we are looking at make Artist more relocatable and locking this down hard to just re-open it not the best plan

I'll go head and close this and we can use #31748 to sort out the current state.

@tacaswell tacaswell closed this May 26, 2026
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.

6 participants