-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Add public API for setting an axis unit converter #19229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This would not be enough as #10206 added a cut-out (which was refactored a bit in #13738 and #14363) to not try and convert numbers. In addition to adding |
I think we could remove the cutout and make dealing with numbers the prerogative of the converter? |
FYI I've decided to solve this in seaborn by internally coercing data to strings in situations where it should receive "categorical" treatment. I I think, for now at least, I don't need any changes in matplotlib to support this particular use-case. I'm going to close the issue, but if you think this is a good idea independently of my narrow problem, feel free to re-open. |
I think we should keep this open for the upcoming unit work. |
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! |
* Add explicit converter setting to Axis Closes #19229 The replacement is the get/set_converter method. This includes changes to use the getter and the private setter in the qt figure options dialog menu. The choice to use the private setter was a defensive one as the public setter prevents being called multiple times (though does short circuit if an identical input is provided, which I think is actually true here, therefore the public one is probably functional (and a no-op).) It is not clear to me on analysis how the unit information is or was lost. A quick test commenting out the two lines which reset converter/units displayed no obvious detrimental effect to removing those, suggesting that even if once they were necessary, they may no longer be. These lines were last touched in #24141, though that really only generalized the code into a loop rather than copy/pasted x and y behavior. The original inclusion of resetting was in #4909, which indicated that the dialog reset unit info. AFAICT, that is no longer true, though I have not rigorously proved that.
Problem
I would like to define and use a custom unit converter class. The existing
mpl.units.registry
system is type-based, which does not work for my usecase. I need my converter to generalize over types. But I also know exactly which (existing) axis objects should use the converter.The closest I can get in associating a custom converter with an existing axis, following the code in
axis.update_units
isProposed Solution
A public
axis.set_converter
API would solve this problem, e.g.The idea is that this would basically do what
Axis.update_units
does, but consuming aConversionInterface
rather than consuming data and then getting a converter from the registry.Additional context and prior art
The other thing I would mention is that I could probably work-around this problem if the registry lookup were based on the container
dtype
rather than the type of the individual elements (as is currently the case). But that seems to complexify the existing API, whereas the this proposal would add an orthogonal API, and it is probably better for that reason.The text was updated successfully, but these errors were encountered: