There are (at least) two third party packages that implement this: https://github.com/joferkington/mpldatacursor/, https://github.com/anntzer/mplcursors (disclaimer: I wrote the later).
I am not convinced that this needs to be part of the core library.

I disagree, this is in my top 3 things I significantly miss when I move from Matlab to python. And I hear other matlab users constantly comment on the lack of the feature in python.

Most average users just want to plot and then use the tool bar to select the way they access the plot. The python toolbar has greatly improved over the years and I love using it. With that being said a default Data Cursor which also moves with the arrow keys would be a tremendous add. Otherwise it is not easy to see several exact values across the plot and/or image.

Thanks for the links, I will try them out.

I don't see why it shouldn't be a feature of Matplotlib!

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

Reopening since this is a valid request (or at least should be closed by decision, not lack of response).

Semi-OT: Do we have an (efficient) „Artist under cursor“ (or more general „Artist at point“) mechanism? This would be the basis for any serious data interactivity and would IMHO need to be a core feature.

You'll need to iterate over all artists anyways, and call contains() (the second item of the tuple contains the relevant info) or some reimplementation of it (mplcursors has one). For scalarmappables there's also get_cursor_data.

This was discussed in the dev-call and the conclusion is that it seems unlikely that we will accept a PR doing this. Partly because it will be very hard to do it without any performance penalty. Hence, those that want this are referred to the third-party libraries linked above.

You'll need to iterate over all artists anyways, and call contains() (the second item of the tuple contains the relevant info) or some reimplementation of it.

@anntzer Out of curiosity, would it be possible (at least for pixel backends) to create a second pixel image that encodes the Artist at that pixel? (E.g. the first artist draws all parts of itself in #000001, the second artist in #000002, etc. when you then want to know which artist is at a certain pixel, you take the color from this encoded image -if it is #000001, you know it is the first artist. The cost would be only at draw-time. I assume that this pixel map would come at a fraction of the overall draw costs since it‘s only the low-level agg calls that are duplicated. The usage would be very fast, because it‘s only a lookup. No iteration over artists and contains-checks.

I suspect that there are a bunch of ways to speed this up. I've thought a bit about what @timhoffm suggest here and also playing the bit-mask game so #000003 means "both artist 1 and artist 2 are in this pixel". I suspect that (atleast in Agg) it would be plausible to compute this in parallel with the actual rendering.

If we added a way of asking "is any part of this artist in this bounding box?", then we could do things like grid the canvas up into 100x100 (or pick any number you want) and use that to filter the set of Artists you would need to look at.

Either of these would also be very interesting for "auto blitting" as we could only clear the parts of the image that include the updated artist and detect which other artists need to be redrawn, but that is going off in a different direction.

Agreed that this is indeed a cute idea. Needs a fair bit of working with the rendering internals, but seems plausible.