Repository navigation
New "vector" method to replace "arrow" #22390
Description
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)
Activity
kmdalton commentedon Feb 4, 2022
plt.vectorsounds like a great addition. In order to behave likeplt.arrow, it mustplt.legend,prop_cycler, andThese are all default behaviors for
plt.arrowbut notplt.annotate.jklymak commentedon Feb 4, 2022
This 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.
QuLogic commentedon Feb 10, 2022
Related: #19705
coleman-isner-cmu commentedon Nov 29, 2022
Hello, @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!
timhoffm commentedon Nov 29, 2022
@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
FancyArrowPatchwith 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 oldarrow()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.
coleman-isner-cmu commentedon Nov 29, 2022
@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!
toniali9 commentedon Dec 13, 2022
Out of curiosity, should the tags be updated?