might also want to confirm that the patch properties are as expected, eg. color.

What happens if you set a label on those elements?

Setting a label to an element like whiskers or caps will revert the next 2 handles into lines. In this case, bp0's whiskers are set a label and color (with @tacaswell's changes). I'll have to dig deeper into this.

We have a labels parameter to boxplot (and it is in the datastructure that goes into bxp) that we currently only use for setting tick labels if manageticks. I think we should also use that to set the label on the boxes.

The fundamental problem is that calling legend with a list of strings is a really (really) brittle API. If it did not exist and was proposed now we would almost certainly reject it. Unfortunately it is too widely used and deprecating it is also off the table so we just have to live with it.

The brittleness comes from the logic of "I have been given N strings, let me find the first N artists in the axes that I know how to make legend entries for and use those!". By setting '_nolabel_' we exclude the lines etc from the "do you want to be in the legend?" search and hence "fix" the problem. This is also the reason why the way it was broken changed between versions. We recently moved from keeping lists of artists by type to a single list of artists so the details about the exact order of iteration of children of different types at the same zorder changed (now strictly the order added, previously runs of same type).

The other ways of making legends (either passing both artists and strings ("use these labels for those artists"), passing a list of artists ("ask these artists what their label should be and then put in legend"2 or calling with no arguements ("find anything that has a suitable label and put it in the legend") are all significantly better APIs (easier to understand and not brittle).

If the user set a label on the whiskers, it is presumably because they are doing ax.legend() or for some other reason accessing obj.get_label() and we definitely should not break them to support the list-of-string use case. If we set the label on the patches then ax.legend() will "just work" and let users get away from the very sub-optimal way they have to do it now.

We have a labels parameter to boxplot (and it is in the datastructure that goes into bxp) that we currently only use for setting tick labels if manageticks. I think we should also use that to set the label on the boxes.

I've implemented this idea so now we can call ax.legend() with no parameters to get a properly labelled legend. Changing other labels will still add them to the legend but at least now they're labelled correctly.

Talked about this on the call.

We like the implementation, but it needs a rebase.

@saranti Did you mean to close this?

@saranti Did you mean to close this?

No, I only meant to rebase. Can you re-open it please? 😃

Continued on PR #27711