I can't remember where this was discussed but I always thought that a problem here is that arrow is explicitly for when the data should be visualized as arrows; annotation doesn't make sense because folks aren't trying to annotate anything. I also forgot why quivers don't work here and this was maybe as part of a request for a vector like thing.

But I do agree on maybe consolidating the underlying primitive/patch to just one type if possible.

The fundamental problem with arrow() / FancyArrow is that it's shape is fixed in data coordinates, so appearance strongly depends on axis scaling and can look weird. IMHO this is broken by design.

This is solved by FancyArrowPatch. Unfortunately, we don't have a top-level function to only create a FancyArrowPatch. You can either create that patch manually and add it using add_patch() (which is a rather unusual API').

See https://matplotlib.org/stable/gallery/shapes_and_collections/arrow_guide.html#arrow-guide for a description of the existing possibilities.

annotate() OTOH does two things: 1) It creates a FancyArrowPatch 2) It can set a text at the end of the FancyArrowPatch. If you don't pass a text, annotate() is basically the missing top-level function to create the FancyArrowPatch. But I agree that "to create an arrow, make an annotation without text" is not great either.

Ideally, arrow() would return a FancyArrowPatch, but for historic reasons we're not there.

The above methods are for "create a single arrow from (x,y) to (x2, y2)". quiver() OTOH is used to visualize vector fields. 1) It's intended for many arrows. 2) It's mainly to show directions, not have given start and end points. You'd have to calculate a bit and set appropriate kwargs to get the start and end points at the positions you want.

It was decided in the dev call today that we want to deprecate arrow() because of its awkward dependence on the axis scales.
The deprecation period should be extended.

As an alternative, we want to introduce a similar replacement vector(x, y, dx, dy, ...) where the parameters are still in data space, but the arrow shape is not tied to the data. This should be implemented based on FancyArrowPatch which is also the basis for annotate() arrows. The additional parameters will be governed by the FancyArrowPatch capabilities, maybe be simply arrowprops like in annotate(). We may try to make an effort to choose their defaults in a way that will result in an arrow similar to arrow() with default settings. Whether that's possible and reasonable is to be tested.

The arrow() deprecation should point to vector() and annotate() depending on users needs.

@timhoffm, plt.vector sounds like a great addition. Will it possible for the function to

• add labels / handles to the current axis for plt.legend,
• automatically choose colors from the prop_cycler, and
• automatically set the x-y limits?

These are all default behaviors for plt.arrow but not plt.annotate.

We can easily extend the deprecation period.

I think discussion of the new vector method should perhaps get its own issue.

The arrow() deprecation should point to vector() and annotate() depending on users needs.

Just to be clear, I don't think the arrow deprecation needs to wait for vector to be created. annotate is a reasonable work-around, and arrow is fundamentally broken and a big foot cannon for users...

Just to be clear, I don't think the arrow deprecation needs to wait for vector to be created. annotate is a reasonable work-around, and arrow is fundamentally broken and a big foot cannon for users...

I beg to differ. #22390 (comment) explains that annotate is not a full replacement. We should have vector in place, so that the deprecation note can reference that as well and users have an alternative to turn to.

My point is that there is nothing to fully replace: arrow is fundamentally broken. The proposed vector is a great enhancement proposal, but whether anyone pushes that through or not doesn't obviate the need to get rid of arrow.

Of course there is on 1:1 replacement because the rendering is broken. But conceptually, you can do 70% with annotate() and will be able to do an additional 20% of the original functionality with vector(); numbers are only a very coarse estimate. Again see #22390 (comment) for why annotate() is not a full replacement.

When we deprecate, I want to be able to direkt users to the 70% + 20% alternative.

Arrow has been in for decades and has apparently quite some usages despite its shortcomings. There is no hurry to to take it away and we have to provide an as good as possible migration path for the existing users.

In practice, I suppose that we can get vector into 3.6 so there should be no difference to the user. But technically, IMHO the deprecation should depend on the vector introduction. If we don't get vector into 3.6, the deprecation should be delayed as well.

Sure, well we can close this, but I'm not holding my breath over the long-standing problem getting fixed.