Skip to content

Add pie artist - #32359

Open
robertoffmoura wants to merge 15 commits into
matplotlib:mainfrom
robertoffmoura:add-pie-artist
Open

robertoffmoura wants to merge 15 commits into
matplotlib:mainfrom
robertoffmoura:add-pie-artist

Conversation

@robertoffmoura

@robertoffmoura robertoffmoura commented Sep 16, 2026 •

Copy link
Copy Markdown
Contributor

This PR is a follow up to #32320. It adds a Pie artist class and deprecates PieContainer. legend.py checks for a get_legend_handles method, so compound artists can expose their handles.

Previous state:

ax._children = [wedge1, wedge2, wedge3, text1, text2, text3],
ax.patches = [wedge1, wedge2, wedge3]
ax.texts = [text1, text2, text3]
ax.containers = []
pie_container1.wedges = [wedge1, wedge2, wedge3]

State after this PR:

ax._children = [pie1],
ax.patches = []
ax.texts = []
ax.containers = []
pie1.wedges = [wedge1, wedge2, wedge3]
pie1.texts = [text1, text2, text3]

AI Disclosure

AI used to gain understanding of the existing code

  • Use an expressive title, e.g. "Fix title font property precedence"
  • New and changed code is tested
  • N/A Plotting related features are demonstrated in an example
  • New features and API changes have release notes
  • Documentation complies with general and docstring guidelines

@timhoffm

Copy link
Copy Markdown
Member

Thanks a lot for working on this. I think this PR is going in a very promising direction, in particular by making Pie a proper composite object and moving ownership of the wedges/texts under it rather than keeping them as unrelated direct children of the Axes. Though we have to carefully decide whether we can afford the related API breakage and whether we could smoothen the transition.

On a broader context, I think we need to think quite carefully about the broader object model this implies.

One question is property propagation. Once Pie is an Artist that owns other Artists, what should e.g. set_visible, set_zorder, set_alpha, transforms, clipping, picking, etc. mean for the aggregate and its children? Some of these have fairly natural group semantics, while others do not. I would prefer not to make these decisions pie-by-pie if what we are really introducing is a general notion of a compound/grouped Artist.

Relatedly, I wonder whether this points towards a broader ArtistGroup / CompoundArtist abstraction. Potentially there is a subset of the current Artist functionality that is structural—Axes/Figure association, ownership, child traversal, lifecycle, staleness, drawing order, visibility, removal, etc.—and could eventually live in a common base of both ordinary Artists and grouped Artists. A group would then not automatically inherit visual properties for which propagation semantics are unclear.

The proposed get_legend_handles() mechanism also looks useful, but I think we should validate that abstraction against the other existing aggregate plot types before making it public API: bars, errorbars, stems, and stackplots in particular have different 1-vs-N legend-entry semantics.

So overall: I think this is very much the right direction, and it gives us a concrete implementation to reason about. But because it potentially establishes a more general compound-Artist model, I would like us to spend a bit more time on those semantics before locking in the API.

@story645

Copy link
Copy Markdown
Member

I would like us to spend a bit more time on those semantics before locking in the API.

I think also the interaction/boundary between data container and artist container as data containers get phased in. Attn @ksunden

This branch has not been deployed

No deployments
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.

4 participants