BUG: plotting with Numpy array subclasses is slow with Matplotlib 3.1.0 (regression)

[astrofrog]

Bug summary

Astropy implements a ConversionInterface so as to be able to plot quantities with units (represented by the astropy Quantity class, which is a Numpy array subclass). However, this functionality is broken with Matplotlib 3.1 as it looks like Matplotlib now tries to iterate over every element of the array we are trying to plot.

Code for reproduction

import numpy as np
from astropy import units as u
from matplotlib import pyplot as plt
from astropy.visualization.units import quantity_support

values = np.arange(1000000) * u.m

with quantity_support():
    plt.hist(values, bins=50)

plt.savefig('test.png')

Actual outcome

Python hangs.

Expected outcome

This was previously very efficient.

The commit that broke this was 9eac832 (sorry @jklymak!) - and in particular the issue is that Quantity is an instance of collections.abc.Iterable, so the first 'if' statement doesn't get executed and instead Matplotlib iterates over all values. Actually what is strange is that this should also cause slowdown for plain numpy arrays, which are also instances of Iterable, and this might happen, but isn't as noticeable. What is different here is that the Quantity initializer is slow enough that this is noticeable.

We didn't notice this sooner as this was only really tested with large arrays in the docs, which aren't run against Matplotlib dev...

[jklymak]

Ping @anntzer who suggested this change :-). I’m away from my computer for a few days so I can’t look at this. Hopefully it’s an easy fix.

[jklymak]

It’s a bit strange that the first element of your quantity is an iterable. Note the check is for X[0] which is mean to see if this is a list of lists. Does each element have to be an iterable?

[astrofrog]

Ah I see the issue, indeed Quantity(...)[0] is also a Quantity which is still an array subclass, hence why it is still considered an iterable.

[anntzer]

I guess the offending line could be changed to X.ndim == 1 and np.ndim(X[0]) == 0. Sure, you'll pay an (implicit) conversion of X[0] to ndarray but we already converted X to an ndarray the line just above so it's not a big deal...

[astrofrog]

See #14289 for a fix

[anntzer]

Closed by #14289 (AFAICS).