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 are test_backend_pdf.py::test_determinism_hatches which uses ax.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 about ax.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 having pint tests?

General unit support strategy.

import matplotlib.pyplot as plt
import numpy as np

import pint

ureg = pint.UnitRegistry()
ureg.setup_matplotlib(True)

x = [1., 2] * ureg.cm
height = [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 indexing

During 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 subscriptable

During 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 on pint, but I could be wrong. I opened hgrecco/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 in test_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)