• ShouldPieContainer inherit fromContainer as I have currently done?

Container falls short for our needs here. It is basically a tuple of artists withremove() propagation and a CallbackRegistry (which AFAICS we nowhere use). That simple tuple approach does not suit the more general case that we have not just one type sequence of Artists. In fact, onlyBarContainer really fits in. AlreadyErrorbarContainer andStemContainer have to work around the limitation using tuples of tuples, which is not a good API.

I think we need to come up with a more generic concept. For a start, I'd say make your own type (i.e. copy the remove method) and define whatever minimal API is reasonable. If we know what kind of API we want to have based on this example it's easier to design a more generalArtistCollection orCompoundArtist.

On a side-note we want this to not only be pure collections, but be a semantic entity, likeStepPatch, i.e. there may be (not necessarily from the start) semantic functions, that non-trivially manipulate multiple properties of the artists; e.g. setting the pie values would need to recompute positions of all wedges and texts and update the text content.

Edit: The case is similar togrouped_bar(), where we currently also only have a provisional class with functionality and minimal guarantees.

• So far I have added very few new tests, since most of thepie_label functionality should be covered by existingpie tests that use thelabels and/orautopct parameters. Is is better to duplicate this coverage?

If writing from scratch, I would mostly test the functionality onpie_label() directly and only ensure basic propagation frompie() topie_label(). Given there are already many tests onpie() that is good enough for a start. I would not duplicate but rather move coverage out ofpie() tests and intopie_label() tests. But that is a nice-to-have. If done, I'd rather make this a separate cleanup PR.

OK,PieContainer is now its own class with its ownremove method.

For complete backwards compatibility, we need "texts" to be returned as an empty list whenlabeldistance isNone. I think both my current and previous implementations broke that.

In draft for now while I think about how to address that. Suggestions of course welcome!

Edit: this is now addressed by the next push.

Apologies - just found some doc changes that I had missed before. None of the examples now unpack or index the return value.