Repository navigation
New "vector" method to replace "arrow" #22390
Description
Activity
plt.vector sounds like a great addition. In order to behave like plt.arrow, it must
- 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.
Reacted by Jody Klymak, Tim Hoffmann and Ian Hunt-IsaakThis would take some work, but I don't think there is anything subtle about it - definitely a good medium scale project for a new contributor if they were up for being careful with it.
Reacted by hannahHello, @QuLogic ! I am working with a team of Carnegie Mellon Students who are interested in contributing to this issue for a class assignment. I just read the Vector #22435 draft pull request discussion, and it seems like the specifications for vector have changed since the pull request was made. Are all of the new specifications found here?
Additionally, should we create a new pull request, or is there a way to add on to the draft pull request? Thanks!
@coleman-isner-cmu Thanks for you interest! However, I'd be catious to choose this for a class assignment. The challenge here is not the implementation (which is basically just creating a FancyArrowPatch with the correct parameters), the challenge is the API design, which requires a lot of experience and knowledge. As you can see by the discussion, this is quite a difficult API design topic influenced by a number of considerations like compatibility (the old arrow() API), consistency (how does this relate to other parts of our API), clarity, usability, etc.
You can discuss these topics in your class, but I don't expect students to be able to come up with a production-ready API design in this context. Note that we have very high quality expectations for new API, because its quality defines how easy people can work with matplotlib, but once released API is very hard to change. This has to be 100% and first-time right when we integrate it.
I'd say that Are all of the new specifications found here marks important corner stones for the design. It's not a full specification. There are a lot of details to be filled in and I expect that there will still be lots of discussions. This will be a bumpy ride.
@timhoffm Thanks for the feedback! Our actual class assignment does not necessarily require that our commits are accepted. So, we may implement those cornerstones anyway, and then you can use or not use them as you all please.
Do you have any suggestions for more straightforward parts of this issue that we could assist with? Or another issue of medium size elsewhere in the project or 2-3 small/easy issues that could use attention? Thanks!
Out of curiosity, should the tags be updated?
It was decided in the dev call today that we want to deprecate arrow() because of its awkward dependence on the axis scales. ...
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.
Originally posted by @timhoffm in #22382 (comment)