MNT: Remove auto-flattening of input data to pcolormesh #24638
Conversation
| # Turn it back on by restoring the array (must be 1D!): | ||
| pc.set_array(z.ravel()) | ||
| pc.set_array(z.ravel() if pcfunc == plt.pcolor else z) |
There was a problem hiding this comment.
Both of these situations feel undesirable...
- The
must be 1D!is the way it currently is and doesn't feel right after we've initialized our array with the 2D versionpcolor(z). - It also doesn't feel great to change this and have to do the
if pcfunc ...and change between 1D and 2D depending on which pcolor incantation I chose.
There was a problem hiding this comment.
The flattening in pcolormesh is a historical artifact; I think the move to accept it as fundamentally 2-D is good.
Pcolor is rarely a better choice than pcolormesh. When it is, it is likely because it can generate a set of
colored quadrilaterals that don't have to fill out a 2-D domain. I think we should embrace this difference between
pcolormesh and pcolor, so I don't have a problem with your special-casing in the test. I'm open to discussing
ideas for backwards-compatible improvements to pcolor, so that it could also take a 2-D array in set_array,
but it doesn't seem like a priority.
|
This is included in #25027, correct? |
If someone passes in a 2-D array, we should keep that in the array data
f57dc5a to
f56d58e
Compare
Yes, I've rebased that PR onto this branch to get these updates. |
|
Ping; this PR apparently breaks seaborn (see issue linked above) and presumably other libraries that make assumptions about the shape of the data attached to artists added by axes functions. I appreciate that there isn't a straightforward path to noisily warning about upcoming changes in artist properties, but could I ask that this change be delayed for at least a version cycle or two to allow downstream packages to adjust? |
|
Thanks for the heads up. Note that this isn't targeted at 3.7, so we do have some time to think about the best approach here. I guess we could warn whenever I agree, we should probably do some kind of warning/compatibility helper here. |
|
Let's discuss on an issue? |
PR Summary
Opening this as a draft for discussion.
If someone passes in a 2-D array to
.pcolormesh()should we automatically call.ravel()on it? See question from @jklymak here: #24619 (comment) Flattening is what historically has been done, but we've been moving towards QuadMesh being a primary 2-D collection lately and could get rid of this restriction on flattening input.The updates here are all primarily surrounding what shapes the returned arrays are from the function calls and how to compare them, so drawing hasn't changed. Also note that this would introduce a deviation between
pcolor(z2d).get_facecolors() == colors1dwhich returns the flattened array, whilepcolormesh(z2d).get_facecolors() == colors2dreturns the original shape of the array passed in.Collectionclasses have a lot of "1D list of objects" method handling in them, but inQuadMeshthere is additional handling for the known 2-D structure of the arrays (mesh in the name).pcolor()returns aPolyCollectionwhich is a 1D list of Polygons, and if there are masked elements it will actually shrink the list and not add that Polygon, so it would require more book-keeping (maybe adding a newPolyMeshCollectionjust for pcolor) to get the 2-D logic right.PR Checklist
Documentation and Tests
pytestpasses)Release Notes
.. versionadded::directive in the docstring and documented indoc/users/next_whats_new/.. versionchanged::directive in the docstring and documented indoc/api/next_api_changes/next_whats_new/README.rstornext_api_changes/README.rst