Tim Hoffmann

`pie_label` method: I'm a bit sceptical. If we didn't have labelling functionality at all in `pie`, that might be the way to go. But as is, there's not much new...

Good summary! This is *one* viable way to make the API more consistent. > I think we should offer the formatting option as it will be hard to discourage use...

> Edit: I guess you _could_ detect whether the format string contains "%}". If it does, give it fractions. If not give it absolute values. Yes, I've briefly thought about...

> Named placeholders would give a lot more flexibility... Great idea. Add this format-string as acceptable input for `inner_labels` and `outer_labels` in https://github.com/matplotlib/matplotlib/pull/29152#issuecomment-2483918655 and we have a compact and clean...

Side note on naming: I've briefly pondered whether in would make sense to bikeshed `outer_labels`, `inner_labels` to replace the "label" part; motivation: set it more clearly apart from `labels`; e.g....

> Though could this also be the external function `pie_label`? Not easily. See https://github.com/matplotlib/matplotlib/pull/29152#issuecomment-2484257688 for the issues I see with `pie_label` function.

Searching for pie chart images on google has significantly more inner labels than outer labels. So inner placement should be the default, exact number t.b.d. (likely 0.6 currently used for...

**TL;DR Overall, I feel both approaches the `wedge_labels` and `inner/outer_labels` are perfectly managable and concise. To me it boils down to a semantic preference: Do we want to encode the...

Sorry, I've not remembered the format-string variant. The cases N wedges with N `wedge_labels` are indeed ambiguous by the structure of `wedge_labels`. Nevertheless, in these special cases we can check...

I believe we should have a dedicated backend version scheme independent of matplotlib version numbers, because we want to communicate EffVer semantics on the backend. That’s not possible when just...