Summary

Extracted from#12021 (comment). This is a tracking issue so that we can close#12021 but the idea is not lost. It does not need immediate action (and may even be hard to act upon).

There is no built-in size check for the data in _CollectionWithSizes subclasses. For example, forPathCollection, one can have 10 paths, 4 sizes and 2 edgecolors.

import matplotlib.pyplot as pltfrom matplotlib.collections import PathCollectionfrom matplotlib.path import Path paths = [Path([(0, 0), (0.5, i), (1, 0)]) for i in range(10)]# 10 paths, 4 sizes, 2 edgecolors:pc = PathCollection(paths, sizes=s, facecolor='none', edgecolors=['r', 'g'])ax = plt.gca()ax.add_collection(pc)ax.set(xlim=(0, 3), ylim=(0, 20))

The behavior is largely undocumented (though some plotting functions mention cycling over properties like colors). AFAICS: The paths effectively define the number of elements. sizes and facecolor etc. are cycled through to match the paths (if there are more sizes that paths, the additional sizes are simply unused. If there are less sizes, the sizes are cycled).

Central question: Is this behavior desired? On the one hand, it can be convenient. On the other hand it can be confusing and lead to unnoticed errors.

Note: I suspect that changing the behavior is difficult. (i) would need deprecation, which is cumbersome but possible, (ii)thing (e.g. paths) and properties (sizes, facecolors) are currently decoupled. They are brought together at draw-time. If we do size checks, they likely can also happen only at draw-time. We have the individualset_* method and size checks in there would prevent any later change of the number of elments:set_paths(paths); set_sizes(sizes) would mutually exclude changing the number of elements. Note that this is similar to#26410, but I think we cannot get away with a collectiveset_XYUVC style solution here.

Proposed fix

No response