So this is a major overhaul that might create deprecation issues with the third party packages the conversation interface is aimed at. Is there buy in/packages that need this functionality? And can it be achieved w/o renaming convert?

So this is a major overhaul that might create deprecation issues with the third party packages the conversation interface is aimed at. Is there buy in/packages that need this functionality? And can it be achieved w/o renaming convert?

Thanks for the quick response, in this PR as proposed I have markedconvert as a pending deprecation (because I think this conversation is needed, and possibly with packages that implement the interface). I have made everywhere that previously calledconvert backwards compatible and it would be up toMatplotlib to determine the deprecation timeline. So other than raising warnings, this change should not affect implementers of theConversionInterface, and it would be safe to provide bothconvert andto_numeric.

Regarding the buy in, I am not sure, but I believe this change is needed becausepandas uses a different date converter. Pandas does subclass theAutoDate{Formatter,Locator}(see pandas) and it provides those in itsAxisInfo, but when using theAutoDate{Formatter,Locator} provided by Matplotlib (which would seem like it should work) or the ones provided by pandas I'm getting an exceptionValueError: year 4320917 is out of range. When debugging the data, the data is a valid UNIX timestamp, but not a valid ordinal, and is caused by theDateLocator callingnum2date when the value needs to be converted into an object, but since theDateLocator has no way to determine what the value was before it converts it incorrectly.

I believe my issue is related topandas-dev/pandas#18344, and now that I have prepared this PR, I will be trying to make sure the tests pass, and testing my code with a patch to pandas that implements afrom_numeric.

Regarding the name change, I believe this could be made without a name change, but it sacrifices the readability and makes the functions slightly ambiguous. Arguably you could make the methods beconvert andunconvert, but which direction are they converting? Without reading the documentation it feels likely that someone might pick the wrong method, and I believe it would be better to start transitioning away from an ambiguous name, but potentially always leaving this a pending deprecation and falling back to the old method.

There have been lots of discussion about fixing units in Matplotlib, including the problem of calculating the inverse. Currently my understanding is that there is a new data model under development that will address this by@tacaswell and@story645. How does this PR fit into those plans? I’m also not in favour of renaming a long-standing method for purely aesthetic reasons.

There have been lots of discussion about fixing units in Matplotlib, including the problem of calculating the inverse. Currently my understanding is that there is a new data model under development that will address this by@tacaswell and@story645. How does this PR fit into those plans? I’m also not in favour of renaming a long-standing method for purely aesthetic reasons.

I'm not aware of those plans, I can possibly help with those plans if needed. I was mainly taking a stab at this because it looks like it has been a longstanding issue and it affects me directly. So rather than just patching it internally or updatingpandas's formatters/locators I figured something more generic and less surprising would be ideal. If there is an email thread/PR/issue already I can be added to it.

Thanks@terencehonles. This is rather a big step in the API, which will have to be thought through carefully. Please be prepared, that the review process may take some time. While I haven't looked into the details yet, the basic idea looks reasonable.

Apart from the individual comments, please address the following:

• Change all deprecations to 3.3, because 3.2 is already out.
• Make all deprecations pending. While you wrote you did in the PR comment, I don't see it in the code.
• This needs an API change note atdoc/api/next_api_changes.rst for the deprecations. The new to and from methods should also be announced, probably best atdoc/users/next_whats_new.

I updated the deprecations, thepending flag was only on the conversion interface, but I added it to all of the deprecations I added in this PR. Regarding the documentation I figured starting a discussion about the change would be appropriate before spending any more time than I have.

I appreciate you looking at it and@jklymak and any others that might have the chance to offer some input.

I'm not aware of those plans, I can possibly help with those plans if needed

I'm sure that would be appreciated.

https://github.com/matplotlib/matplotlib/labels/units

Note that there are other solutions topandas-dev/pandas#18344 underhttps://github.com/matplotlib/matplotlib/labels/Date%20handling, in particular#15008

The data model work is going to intersect with the units work by better managing the life cycle of when it gets called, but should be relatively agnostic to how we spell the unit conversion.

We talked about this on the dev-call this week (.https://hackmd.io/-fJ2hZcJQz2gfbqzabrZMQ?view#Units-change). We have several concerns:

• the renames are making in very hard to think about and review this set of changes. While we appreciate you work on this, can you back the deprecation and rename ofconvert out of this PR if you want to go forward with this. I think the same goes for thestaticmethod ->classmethod changes.
• in general, it is not clear that the "unconvert" is always well defined. For example if the user gives us bothnp.datetime64 ordatetime.datetime we lose the information about which one we started as so don't know how to go back to what the user provided us. If this is going to go in theunconvert method is going to have to be optional for over and provide a way for the the converter to declare that itcan't be inverted.

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.