[Bug]: Unexpected behavior of scatter.legend_elements

[ssslakter]

Bug summary

If I have list of colors [1, 2, 3, 4, 5,6,7,8,10] that I use to get legend for scatter, but for some reason it adds extra color 9. Generally I get this problem while having a list of colors that have some missed integers. Also sometimes this function shows less labels then there are colors

Code for reproduction

import matplotlib.pyplot as plt
n = 9
sc = plt.scatter([1]*n,  list(range(n)),  c=[1,2, 3, 4, 5,6,7,8,10])
plt.legend(*sc.legend_elements())
# this will show legend with 1,2,3, 4, 5,6,7,8,10

import matplotlib.pyplot as plt
n = 10
sc = plt.scatter([1]*n,  list(range(n)),  c=[1,2, 3, 4, 5,6,7,8,9,11])
plt.legend(*sc.legend_elements())
# this will show legend with 1,2,3,4,5,6,7,8,9,10,11 BUT 10 is not supposed to be here

Actual outcome

label shows 1,2,3,4,5,6,7,8,9,10,11

Expected outcome

label shows 1,2,3,4,5,6,7,8,9,11 without 10

Additional information

This function seem to randomly fill up the rest of colors in the legend even when there are less points then it shows in legend

Operating system

WSL

Matplotlib Version

3.8.0

Matplotlib Backend

module://matplotlib_inline.backend_inline

Python version

3.11.7

Jupyter version

4.1.1

Installation

conda

[dstansby]

From the docstring of legend_elements():

num : int, None, "auto" (default), array-like, or `~.ticker.Locator`
            Target number of elements to create.
            If None, use all unique elements of the mappable array. If an
            integer, target to use *num* elements in the normed range.
            If *"auto"*, try to determine which option better suits the nature
            of the data.
            The number of created elements may slightly deviate from *num* due
            to a `~.ticker.Locator` being used to find useful locations.
            If a list or array, use exactly those elements for the legend.
            Finally, a `~.ticker.Locator` can be provided.

So to get the behaviour you want you can do sc.legend_elements(num=None).

[dstansby]

So I don't think this is a bug, but I've opened #27846 to improve the example in the documentation.