I thought it was ok to propagate because there is a keyword to control if boxplot manages the ticks or not.

Uh, ok, I did not know about that ... 🤯

I suppose,manage_ticks isn't a justification though. First, it's quite an awkward API to change the effect of one parameter (labels) through another (manage_ticks). Second, you still cannot put labels to ticks, but not get legend entries through theboxplot API.

But let me rethink what the implications for usability and future API changes are. I'll put to draft.

To elaborate more, my thinking was that users would either use do nothing (and we manage the ticks) or passmanage_ticks=False and useax.legend(). However, I did not thoroughly think through the consequences.

If we are messing with the ticks, putting any other artists on the axes is likely to be a brittle so I am not sure how common it would be to have a combination of a boxplot which manages the ticks and some other artists on the axes which requires a legend.

TL;DR: Irrespective of the tick vs. legend labelling issue, the current implementation (#27711) is not generally suitable for legend labels.

After testing:
The current implementation was motivated by and tested with a very special usage scenario, where you make one box perboxplot() call only (see the test removed in this PR).

In more general scenarios (tested here by addinglegend() to the recently rewrittenhttps://matplotlib.org/devdocs/gallery/statistics/boxplot_color.html), one gets

and without re-coloring the individual bars:

In particular:

1. Thelabels parameter is verbatimly copied to each box. - Whether or not one re-styles the boxes, it's not reasonable to have the same label on multiple legend entries.
2. boxplot does not allow individual colors per box in its call. So, by default we have all N identical styled boxes in the legend. Even if we would fix (1) and distribute thelabels elements to these boxes, the boxes would look the same with different labels, which is also not helpful.

So#27711 is only helpful for one very particular use case, but does not yield reasonable legends in other more standard cases. I therefore, suggest to revert it (-> undrafted this PR) and separately start thinking on more scalable approaches.

oh, I agree that is broken!

I thought that vector-like inputs were broadcast across boxplots....

FWIW I think mysecond commit at#27767 would fix the first fruity case above.

FWIW I think mysecond commit at#27767 would fix the first fruity case above.

Yes, but unfortunately it does not generalize well to the more common second case. And there's still helf of the tick/legend duplicity issue.

Long term I think the right answer is to have one legend label per boxplot call

Fundamentally yes! Naming is an issue though, but let's discuss solutions in a separate issue.I'll open one. Let's discuss in#27792.

boxplot does not allow individual colors per box in its call.

#27304 needs a decision and I think is worth pulling back to boxplot too - meaning if the consensus is color keywords do that in boxplot, if consensus is prop keywords do that.

boxplot does not allow individual colors per box in its call.

#27304 needs a decision and I think is worth pulling back to boxplot too

That's orthogonal to this PR, which just cleans up an improper API extension to our current functionality. For new labelling API, please discuss#27792. In particular note, that we could handle different-colored boxes in an extension as well (#27792 (comment)). So, you'd be covered.

Since the only change since@tacaswell's approval was a very minor docstring wording update, I'll merge this with two approvals.