I like the fix. Any reason not to add your example code as a test?

I like the fix. Any reason not to add your example code as a test?

Yep, done!

Failed tests aretest_backend_pdf.py::test_determinism_hatches which usesax.bar. But I don't see what the error could be. I simplified the test to not include any hatches, and it still fails. I compare the three files this test makes using diff, and diff says they are different, but Adobe Acrobat doesn't report any differences, and I certainly cannot see any.

Any hints as to why these are different at the binary level, but not practically different?

EDIT: ooops, had an errant print statement in there what was being appended to the end of each of the stdout streams, and that was different each time. The files themselves are identical. 🙄

I like the point aboutax.bar(['a', 'b'], ['c', 'd']). Unless it's redundant somehow, could you add that as a test as well?

That was a test that failed my original change but now passes, so yay tests! But I think that case is covered in test_category

Cool, never mind then.

Ping@QuLogic@timhoffm@anntzer - you all had comments after two approvals ;-) want to re-approve and merge if you think its an improvement? Thanks!

Discussion on units and numpy functions pending. Otherwise this looks good.

See e.g.#7562 (review),#7562 (comment) for units discussion; some comments are also present e.g. in the errorbar() implementation. (Personally, I think "not being able to use numpy functions at all before units handling" is really not a great policy, but heh...)

Yes, this is truly a PITA

But see latest for an attempt to deal with all the goofy cases (empty arguments, wrapped arguments, singletons, numpy arrays; am I missing any?)

So, can we introduce a testing dependency like pandas for pint so we can have an example of a units package that wraps? They have matplotlib units registry. We can of course skip the test if pint won't install. I think pint is pretty lightweight. W/o that example, its pretty hard to test that we don't break things.

Let's not relitigate this here; there have been extremely long threads elsewhere already.

Relitigate havingpint tests?

General unit support strategy.

importmatplotlib.pyplotaspltimportnumpyasnpimportpintureg=pint.UnitRegistry()ureg.setup_matplotlib(True)x= [1.,2]*ureg.cmheight= [10,20]#ax.bar(datetime(2018, 1, 1), 1,#        width=timedelta(hours=3))fig,ax=plt.subplots()ax.bar(x,height,width=[.2]*ureg.cm)plt.show()

works fine.

ax.bar(x, height, width=.2 * ureg.cm)

fails with

Traceback (most recent call last):  File "/Users/jklymak/matplotlib/lib/matplotlib/axes/_axes.py", line 2057, in _convert_dx    dx = [convert(x0 + ddx) - x for ddx in dx]  File "/Users/jklymak/matplotlib/lib/matplotlib/axes/_axes.py", line 2057, in <listcomp>    dx = [convert(x0 + ddx) - x for ddx in dx]  File "/Users/jklymak/pint/pint/quantity.py", line 1404, in __getitem__    "supports indexing".format(self._magnitude))TypeError: Neither Quantity object nor its magnitude (0.2)supports indexingDuring handling of the above exception, another exception occurred:Traceback (most recent call last):  File "/Users/jklymak/pint/pint/quantity.py", line 1400, in __getitem__    value = self._magnitude[key]TypeError: 'float' object is not subscriptableDuring handling of the above exception, another exception occurred:Traceback (most recent call last):  File "testBar.py", line 14, in <module>    ax.bar(x, height, width=.2 * ureg.cm)  File "/Users/jklymak/matplotlib/lib/matplotlib/__init__.py", line 1643, in inner    return func(ax, *map(sanitize_sequence, args), **kwargs)  File "/Users/jklymak/matplotlib/lib/matplotlib/axes/_axes.py", line 2232, in bar    width = self._convert_dx(width, x0, x, self.convert_xunits)  File "/Users/jklymak/matplotlib/lib/matplotlib/axes/_axes.py", line 2063, in _convert_dx    dx = convert(dx)  File "/Users/jklymak/matplotlib/lib/matplotlib/artist.py", line 180, in convert_xunits    return ax.xaxis.convert_units(x)  File "/Users/jklymak/matplotlib/lib/matplotlib/axis.py", line 1481, in convert_units    if munits.ConversionInterface.is_numlike(x):  File "/Users/jklymak/matplotlib/lib/matplotlib/units.py", line 126, in is_numlike    for thisx in x:  File "/Users/jklymak/pint/pint/quantity.py", line 1404, in __getitem__    "supports indexing".format(self._magnitude))TypeError: Neither Quantity object nor its magnitude (0.2)supports indexing

I think thats onpint, but I could be wrong. I openedhgrecco/pint#751 there to see what they suggest.

I'll note that

ax.plot(0.1*ureg.cm,1,'d')

works, but gives a/Users/jklymak/pint/pint/quantity.py:1377: UnitStrippedWarning: The unit of the quantity is stripped. warning.

@jklymak For future reference for testing,lib/matplotlib/tests/test_units.py already has a quick implementation of a class that wraps a numpy array specifically to allow testing things that work like pint:

@dopplershift yeah, I know about that. But I wasn't sure it was the same enough.. I still think its worth thinking about adding pint as a (optional) test dependency. Astropy too, if they have a robust units framework.

Also your input on#13254 would probably be helpful if you didn't see it.

Well, the whole goal of that class intest_units.py is to be same enough, so...if it's not, we should add to it. What I've been doing there is:

1. Find failure with pint
2. Reproduce failure with our class, adding as necessary
3. Fix problem in matplotlib
4. Verify fixed with pint

(#13254 is in my backlog)