Your PR would need a test that checks that the exception is raised. This should probably go intohttps://github.com/matplotlib/matplotlib/blob/main/lib/matplotlib/tests/test_legend.py

Here is a similar test to see how to check for an exception:

(Also, note that#24063 solves the same issue.)

@oscargus is ValueError the right type of error to raise?
I have never written tests before I will analyse the suggested tests and write accordingly

So raising here is an API change. Are we ok raising without deprecating mismatched list lengths?

There is also an explicit bit of code on L1226 that ensures that if handles and labels are passed as keywords they are trimmed to the same length. Given that we currently are positively discarding excess labels or handles, we will need to warn for one version before we start to raise.

@tusharkulkarni008 Can you look back at the git-blame of when L1226 came in to see if we had any discussion about it at the time?

We may want to change our minds about supporting un-equal numbers of handles/labels but we should understand why we used to support it and make sure we no longer agree with those reasons. While there are some things in Matplotlib that are they way they are because that was the first way someone thought to do something, most things in Matplotlib are there because someone at one point had a good reason for wanting it that way. It is important to understand why things are they way they are before we change them to avoid unintended side effects.

Will do

Also, currently we accept iterables, so you have to handle the case thathandles and/orlabels don’t support__len__.

Please add tests as well.

so you have to handle the case that handles and/or labels don’t supportlen.

Can probably do this withzip_longest + aobject() sentinel + checking to make sure we do not see the sentinel. That said, if we take iterators there may some usage where the labels are an infinite generators for the labels. Currently

fromitertoolsimportcountimportmatplotlib.pyplotaspltimportnumpyasnpfig,ax=plt.subplots()forjinrange(5):ax.plot(np.arange(5)+j)ax.legend(ax.lines, (f'line{j}'forjincount()))

works.

so you have to handle the case that handles and/or labels don’t supportlen.

Can probably do this withzip_longest + aobject() sentinel + checking to make sure we do not see the sentinel. That said, if we take iterators there may some usage where the labels are an infinite generators for the labels. Currently

IMHO the simplest solution is the following:

• Postpone the len-check to the very end of the function, wherehandles andlabels variables are resolved. That way, we cover all sources of thehandles andlabels.
• Wrap the len-check in atry-except block, and do nothing if you cannot determine the length. We need to continue accepting iterators for compatibility, but we don't need to jump arbitrary complex hoops to try and find out how may elements they will give only to be able to give a warning.

I wonder if a warning that an input is being truncated would be enough for the user who requested an exception? I think that would avoid worries about api changes, and any user who wants to pass e.g. a generator can just suppress the warning if they wish.

look back at the git-blame

I think this is not easy in this case as the code is old and has moved around. The code to truncate when both handles and labels were passed was added within a bugfixto ensure passing both in was handled at all.

I can’t see any discussion of the truncation there but my guess is to make it consistent with the case when only labels are passed in. That code can be traced all the way back tohere. The commit that produced that appears to be where Matplotlib moved from subversion to git.

The commit that produced that appears to be where Matplotlib moved from subversion to git.

When the svn -> git conversion was done we lost like the first 6 commits (the first commit we have hassvn path=/trunk/matplotlib/; revision=7 in it). My current theory is that because svn only gives diffs we see a whole lot of commits adding docs and examples that claim to fix bugs with no code changes. That commit is one where all the files got moved so there was a huge diff and we finally start to see the library.

The original svn commits can be accessed athttps://sourceforge.net/p/matplotlib/code/1 etc, but I think it is impossible to graft those back into the tree in a useful way at this point. It also looks like there was a CVS -> SVN transition before the SVN -> git transition.

I think the combination of@timhoffm and@rcomer 's comments is best. We should warn if labels and handles have different lengths only if they have lengths and leave it as just a warning rather than a deprecation warning.

I converted this to draft and moved it to the 3.8 milestone. Re-reading the comments I think the work that needs to be done is:

• only check the length if the inputs actually have length
• only warn because this previously "worked" and we do not want to suddenly start raising exceptions in user code that was running
• add tests of all of the behavior

@tusharkulkarni008 Are you still interested in working on this? If so can we help you to move this forward?

Now replaced by#27004