Many of the converters convert from different units to matplotlib values. I.e. the date converters. So how will you invert if the inversion is non-unique?

As pointed out a few times, I think any co-ordinate that gets unitized should go ahead and be converted, but we should pack the original in w/ the conversion. Then we can always get back to where we started. I.e.x=dict(orig=Xorig, converted=currentconversion)

Can you give an example of the different date units?

The way I've set it up, doing how the back-conversion is done is entirely up to the implementation of theConversionInterface. If needed, what is returned can depend on theunits attribute of the axis, which can change from e.g.m tocm.

Although that is potentially a good idea, it doesn't cover cases where the conversion back is not being done on a data point, e.g.xlim/ylim are almost never the same as an actual data point passed in.

The date converter will acceptdatetime.datetime,datetime.date andnumpy.datetime64 right now. If we convert to ordinal (days since epoch) as we do now, how will we know the correct inversion? Practically this could have an effect if the user overrides the datetime64 conversion, but not the datetime.datetime, and converts, but then the inversion puts the date back in datetime units.

More to the point, if we change the units of the axis, inverting and then re-converting is not garaunteed to be correct if we don't get the original data.

I'm not sure I follow the xlim/ylim issue. I don't see any reason xlim/ylim can't be wrapped in the same way as other data.

That makes sense; we can just make different copies of eachConversionInterface, that inherit everything from aDateConverter, but just have different methods to convert the units back.

Still needs:

• API changes (or what's new?)
• Separate un-converters for each of the date types

@dstansby, I think this should be discussed more before more work is done. As I understand it, the plan for 4.0 is to have a new way of carrying the data around inside Matplotlib. That may be a pipe dream, in which case something like this may be a good half measure, but we should make sure this fits in the roadmap?@dopplershift@tacaswell were particularly interested in better units support.

Thanks for pointing that out - is there a roadmap for 4.0 or anything written down anywhere about the changes to data-carrying? Either way I'm kind of happy to carry on playing with this and writing it up on a zero-merge-expectation basis.

That seems reasonable. There is a paper document.https://paper.dropbox.com/doc/Matplotlib-4.0-WTYwd0NQaSHTjtLUZwkNx

I think there's another version of this kicking around somewhere, and it's clear that something like this needs some more careful thought and design, so I'm going to close this.