Hello, I'd like to contribute on this issue.

Hi @vitorfrois, I recommend that you wait until a few maintainers have chimed in on whether this feature should go into matplotlib and hashed out an API- if you have suggestions you're welcome to propose them. Otherwise (and possibly either way) this will get hashed out on the PR.

The request seems reasonable to me but I'm not sure whether the API would be simple enough to be feasible- do we want three more kwargs on this plotting method, is there a more straightforward way to do this (was thinking allow label and autoprct to take each other's kwargs but that will maybe be messy internal logic) or is it simple?

Actually it has a very simple solution.
At def pie(...):, a swaplabelpct=False parameter was added. Inside the function, I have the statement
if swaplabelpct: labeldistance, pctdistance = pctdistance, labeldistance+0.05
(the +0.05 allows some space between %s and the chart)
And when I print a pie chat with swaplabelpct=True, I get the following result:

If you've already implemented something, you're more than welcome to open the PR. I'm just trying to be upfront that it may not get in.

labeldistance+0.05

Does this padding work for all wedge sizes/ a wide range of percentages?

swaplabelpct=False

I think this is cleaner than my proposal (I was thinking of label and prct locations cause that would provide lots of flexibility) but I'm not totally sold on whether this or a more general solution makes more sense.

I'm not in favour of this request: labeldistance and pctdistance are both provided as kwargs. The user can swap these themselves, or put in whatever value they prefer, if they do not like the default values.

I'm not in favour of this request: labeldistance and pctdistance are both provided as kwargs.

I didn't know about those and should have checked 😶 but then maybe the resolution here is to better documenting that by adding a section to https://matplotlib.org/devdocs/gallery/pie_and_polar_charts/pie_and_donut_labels.html#sphx-glr-gallery-pie-and-polar-charts-pie-and-donut-labels-py

You can make it more explicit if you like, but the documentation is readily available - not everything needs to be spelled out explicitly in an example.

not everything needs to be spelled out explicitly in an example.

Yeah, but I think feature requests are good candidates for making more explicit, and here it's adding a section to an example rather than creating a new one. I'd honestly just move them next to each other in the docs but can't in this case 'cause of the signature (though the existing order doesn't match the signature either...)

ETA: maybe make the docstring more explict: Set to 1.5 to put autoprct outside, set to less than 1 to put labels inside?

Are pctdistance and labeldistance using the same ""units"? Not so clear from the descriptions in that case....

They are the same, but they should be spelled the same here.

I'd honestly just move them next to each other in the docs but can't in this case 'cause of the signature

Just do it. Reorder according to the signature and then move shadow one place. Nobody will notice.

Additionally, we can start a kwarg only deprecation at explode to have the ability of reordering the signature in the future.

Just do it. Reorder according to the signature and then move shadow one place. Nobody will notice.

I also have this question about the sanctity of the signature and matching things up w.r.t. #24470 b/c I currently put hatch next to color and really don't want it at the bottom.

They are the same, but they should be spelled the same here.

OK! Then I think that spelling them the same way (not clear which, I may be inclined to think that radial distance is a bit clearer, although that is also expressed as a ratio, so the unit of the value is not so clear) will take this a long way.

I'm a bit against not having the parameters in the "correct" order, but on the other hand pro making most methods with gazillion arguments keyword only after the most obvious ones (like data being positional, styling kw-only).

(btw, the current doc-string is already out of order with normalize before labeldistance)

I'm a bit against not having the parameters in the "correct" order,

The rough order should be the same, but I think nobody will be confused or complain if the signature is

pctdistance=0.6, shadow=False, labeldistance=1.1,

but the documentation is

pctdistance
labeldistance
shadow

Personally, I mostly ignore the parameters in the signature because the parameter list is much more readable: https://matplotlib.org/stable/api/_as_gen/matplotlib.axes.Axes.pie.html#matplotlib.axes.Axes.pie
I only cross-check in very special cases.

I also have this question about the sanctity of the signature and matching things up w.r.t. #24470 b/c I currently put hatch next to color and really don't want it at the bottom.

My take on this:

• Signature is API. Reordering can only be done after making parameters keyword-only.
• Generally, the order of the documented parameters should follow the signature.
• Slight reordering of documented parameters is ok if we think that logical parameter grouping will be be more beneficial to the reader than the exact order-matching to the signature. If we deviate, we should start a keyword-only deprecation to be able to adjust the signature parameter order later.

I think that this can be closed now.

There is an example explicitly showing this: https://matplotlib.org/devdocs/gallery/pie_and_polar_charts/pie_features.html#swap-label-and-autopct-text-positions

and the documentation is updated:
https://matplotlib.org/devdocs/api/_as_gen/matplotlib.axes.Axes.pie.html#matplotlib.axes.Axes.pie