I think we need to be careful here to handle all the cases from#16258.

I agree,@jklymak, I think that it would be ideal to store the actual data array.imshow already does this:
plt.imshow(np.random.random((5, 5))).get_array().ndim == 2

The current docstrings mentionsvertices (a 2d mesh) andcoordinates (n x 2) mesh, which doesn't really help the confusion here

The reason I chose this simplistic thing was that I didn't want to go down the rabbit hole of deprecation issues. Would it be possible to change that at this point, even? My guess is that people may be usingget_array() andset_array() with expected 1d arrays both ways, so I'm not sure how we would go about adding a 2d option without messing with someone's current 1d implementation.

Even more confusing through this all is that you canset_array() with a different shape than the coordinates or original data!
Try:
plt.imshow(np.random.random((5, 5))).set_array(np.random.random((5, 4)))
and look at where the ticks are.

andQuadMesh will actually tile your missing data for you:
plt.pcolormesh(np.arange(25).reshape((5, 5))).set_array(np.arange(10).reshape((5, 2)).ravel())

The two methods handle the different sized arrays differently. These seem like they could be quite confusing mistakes to track down!

After that long digression... I agree that this current implementation I have here is less than ideal and may lead to more confusion down the line. I would be willing to add 2d capabilities toQuadMesh if people think that is an OK idea. I also would be in favor of starting to add some requirements onset_array() depending on what is stored in the coordinates currently.

I looked a little more into this and the current backend implementors expect the shape of coordinates to be (m+1, n+1, 2), and facecolors/edgecolors to be (m*n). This is baked into the backends already to be flattened arrays and my guess is it would possibly cause a headache to change this.

I just pushed up a new proposed modification that will allowset_array() to accept 2D arrays for QuadMesh now and ravel whatever data they have (either 1D or 2D) into the correct shape internally to pass onto the backends. It maintains current functionality and just extends it to allow 2D data arrays for QuadMesh's.

There could be more checks done on the Python side of things to make sure arrays are the right size etc... But, that also wasn't done before so I'm not sure it should be done.

plt.imshow(np.random.random((5, 5))).set_array(np.random.random((5, 4))) ...

This is the expected behavior due to the way imshow works under the hood (it has both a data array and an extent seehttps://matplotlib.org/tutorials/intermediate/imshow_extent.html). The alternate behavior (the extent changing when you set the data) would be much more confusing.

Does fail loudly (if from a not great place) if you set miss-shapen data? Are there cases that used to fail that now pass?

I am 👍 on this in principle, have a small concern that this is going to mask other bugs.

So do we need tests for the various other input shape combinations? I guess at least, it would be nice to have tests for invalid shapes.

Unfortunately, there aren't really any "bad" shapes now. Quadmesh will accept flattened arrays that are larger or smaller no problem and then either chop the data off or tile it up for you respectively. See this long comment for the background there:#16908 (comment)

I'm hesitant to add a strict check onA's shape/size incase someone is (ab)using that feature. I did have that initially for just the 2d Quadmesh case (see:#16908 (comment)) but I took that away to just delegate the getting/setting of A to the superclass instead.

@greglucas we have a preference for rebasing rather than merging the master branch into feature branches. I took the liberty of doing the re-base and force pushed to your branch.

Thanks! I also noticed that one of the comments was incorrect now too, so I pushed up a change for that just now.

I think this is OK as a logical improvement, but perhaps the next step should be to override Quadmesh.set_array so that it checks that the dimensions of its argument, whether 1-D or 2-D, are consistent with the mesh dimensions set when the Quadmesh was instantiated.