GeezerVison

looking at the function and function calls, I think the arrow function adds in an unncessary layer of indirection given that the only argument actually passed in is the point. I think here it would be a lot clearer to just do:

arrowprops=dict(arrowstyle="<->", shrinkA=0, shrinkB=0)
xycoords = 'figure fraction'

overlay.annotate("", (0, 0.75), (0.1, 0.75)), xycoords=xycoords, arrowprops=arrowprops)
overlay.annotate("",(0.435, 0.25), (0.565, 0.25)  , xycoords=xycoords, arrowprops=arrowprops)
overlay.annotate("", (0, 0.8), (0.9, 0.8), xycoords=xycoords, arrowprops=arrowprops)

Hi @story645 , thanks for the suggestion! I've updated the code to use the direct overlay.annotate() calls as you recommended :)

@story645 I disagree. I intentionally introduced the arrow function as a semantic wrapper. I still find annotate("", xy1, xy2) a really awkward API. This is basically the discussion of #29826 (which is only deferred because we need to agree what the underlying artist should be), and the need for a reasonable high-level API still persists.

I'm not quite happy with reverting the wrapper, but since this is only an internal helper script and does not show up prominently in the docs, it's not worth fighting over.

Sorry, but I also think doc examples are not the place to introduce new API. In this example, the extra arrow function to me felt very distracting once I figured out it wasn't doing anything extra. I would say here if anything then ConnectionPatch should just be used explicitly or the arrow function here should be wrapping ConnectionPatch.

This is not intoducing new API and the code is not user-facing or teaching by intent. In my perspective, it's just a helper function making the example more readable for editors of that code. Obviously, YMMV. Let's not get into the discussion right now.

Sorry, is kinda how I read `intentionally introduced the arrow function as a semantic wrapper. I still find annotate("", xy1, xy2) a really awkward API."