deregister_matplotlib_converters() in 0.25 incorrectly removes Matplotlib converters

[dstansby]

Consider

import matplotlib.units as munits
import pandas as pd
pd.plotting.deregister_matplotlib_converters()

print(pd.__version__)
for key in munits.registry:
    print(key, '\t', munits.registry[key])

deregister_matplotlib_converters() should only remove pandas converters, and not any other converters in the MPL units registry, but in pandas 0.25 it removes some of the Matplotlib converters.

Problem description

For pandas 0.24 this prints:

0.24.2
<class 'decimal.Decimal'> 	 <matplotlib.units.DecimalConverter object at 0x1135515f8>
<class 'datetime.datetime'> 	 <matplotlib.dates.DateConverter object at 0x11ed79cc0>
<class 'datetime.date'> 	 <matplotlib.dates.DateConverter object at 0x11ed79c88>
<class 'numpy.datetime64'> 	 <matplotlib.dates.DateConverter object at 0x11ed79c50>

But for pandas 0.25 it gives

0.25.0
<class 'decimal.Decimal'> 	 <matplotlib.units.DecimalConverter object at 0x1133cd588>

This means pandas.plotting.deregister_matplotlib_converters is removing some of the built in matplotlib converters from the units registry when it shouldn't be; this is causing some of our tests to break upstream (xref matplotlib/matplotlib#14859)

[dstansby]

Ah, actually I think the problem might be that pandas registers it's own converters, and then deregister_matplotlib_converters() deletes them (correct behaviour), but does not restore the original Matplotlib converters. I think #27480 is the easiest way to solve this issue, by just relying on the Matplotlib converters when available.

[TomAugspurger]

deregister_matplotlib_converters should restore the original ones. I'd prefer fixing the restoration to outright removing the old ones. I think we got pushback last time we changed this.

[dstansby]

Why the pushback (out of interest)? Naïvely it seems to me that maintaining two different implementations (one in mpl, one in pandas) of the python-native datetime converters seems wrong to me; there is only one correct way to do the conversion.

[TomAugspurger]

I don't recall the details, sorry.

…

On Fri, Jul 19, 2019 at 11:28 AM David Stansby ***@***.***> wrote: Why the pushback (out of interest)? Naïvely it seems to me that maintaining two different implementations (one in mpl, one in pandas) of the python-native datetime converters seems wrong to me; there is only one correct way to do the conversion. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#27479?email_source=notifications&email_token=AAKAOIURAOT2QTSPRX64YW3QAHTS5A5CNFSM4IFHOTTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2MDRZQ#issuecomment-513292518>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKAOIVMPRT2QC3V2O7BLCLQAHTS5ANCNFSM4IFHOTTA> .

[jklymak]

I think it'd be great if pandas just used Matplotlib's converters, but can easily imagine that would cause issues, particularly as our converters changed around 3.0. It just seems like a nuisance to have two sets of converters.

But for sure, it would be nice if the matplotlib converters were re-loaded when the panda ones are deregistered 😉

[TomAugspurger]

I'm 100% on board with just using Matplotlib. I don't think any of the current pandas maintainers understand of converters :) Just need to figure out a way to get there that isn't too disruptive.

[jklymak]

Yeah, I imagine back-compatabilty would be the biggest problem if you are still supporting MPL 2.x

[jorisvandenbossche]

I'm 100% on board with just using Matplotlib. I don't think any of the current pandas maintainers understand of converters :) Just need to figure out a way to get there that isn't too disruptive.

That's not fully correct I think. The pandas converters do provide more features and a better user experience, but, we are speaking then about the Period-based converters (and we do convert regular datetime64 timeseries to periods).

[jorisvandenbossche]

Anyway, justed wanted to say: it is not that easy to just move to matplotlib's converters. But if people are interested in discussing this more in depth, let's open a new issue for it (as we should for sure fix the regression of not restoring the converters correctly).