René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Move towards making Axes.lines, Axes.patches, ... read-only views of a single child list.","articleBody":"Currently Axes stores child lines in Axes.lines, child patches in Axes.patches, etc.  This may be slighly inelegant compared to having a single list of children, but more importantly, #17231 revealed another problem with this design.  Currently, artists with the same zorder and the same type (line, patch, etc.) are drawn in the order in which they were inserted in their respective list (relying on the fact that `sorted` is stable, i.e. preserves original order for ties).  This is not some obscure edge case, but in fact occurs all the time when one plots multiple lines in an Axes: by default, the lines all share the same zorder and are only kept sorted form their insertion order!  However, #17231 revealed that this doesn't work in the presence of artists of two different types (in this case, a LineCollection representing errorbar \"bars\" and a Line2D representing the markers at the ends of the errorbars): the two artists go into separate lists (Axes.collections and Axes.lines) and then the only way to ensure that one is drawn before or after the other is to give them *different* zorders (specifically, right now the implementation of Axes.get_children always puts collections before lines in case of ties).  Different zorders sound fine, until you start having *two* errorbars, each with their bars and markers: now you want to draw in the order [bar1, marker1, bar2, marker2], but assigining different zorders to the bar and marker (but sticking to some default) will result in [bar1, bar2, marker1, marker2].\r\n\r\nPutting all child artists in a single list would fix this problem by maintaining a single consistent insertion list.  This doesn't mean we need to get rid of Axes.lines, Axes.patches, etc.; in any case these have probably been around for too long for it to be reasonable to remove them.  However we should likely turn them into read-only lists, and then properties recomputed on-access from the children list (`tuple(art for art in self._children if isinstance(art, Line2D))`).  In fact there are other reasons for doing so; for example right now we go to great lengths to prevent reassigning artists from one Axes to another, but (I think?) one can just move an artist from one Axes' lines list to another Axes' and one will still have achieved the same result (modulo also adjusting the transform, etc.).  We simply do not want users to be able to append new artists to the list.  Another nice thing about this change is that I believe it's actually doable with a proper API deprecation period -- one \"just\" needs to write a proper list subclass which warns on the right methods.  I think the only use case which this change would prevent is people *deleting* artists from Axes.lines; however, I would argue that the canonical way to remove an artist is `artist.remove()`; moreover, if we really wanted to still support that we can always keep using a custom list subclass which allows that (and forwards the deletion to the master children list).","author":{"url":"https://github.com/anntzer","@type":"Person","name":"anntzer"},"datePublished":"2020-04-27T08:22:18.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/17247/matplotlib/issues/17247"}