Prepare for ragged array warnings in NumPy 1.19 #17289
Conversation
|
Do you want to get these is as-is and address the rest later or hold these to fix them all in one shot? |
|
Ah, telling |
|
This is mostly done, except for plt.plot((np.arange(5).reshape((1, -1)), np.arange(5).reshape(-1, 1)))which is of course, non-sensical. It currently checks that it raises a |
|
Not sure if that's the best last commit, but that should fix all the warnings. |
|
I pushed a commit to fix |
tacaswell
added
the
Release critical
|
Do we want to backport this to 3.2.x? |
lib/matplotlib/cbook/__init__.py
Outdated
| x = np.asanyarray(x) | ||
| try: | ||
| x = np.asanyarray(x) | ||
| except np.VisibleDeprecationWarning: |
There was a problem hiding this comment.
So, what happens after the deprecation period?
There was a problem hiding this comment.
I assume it'll be a ValueError, but it wasn't clear in the NEP.
The `segments` parameter is a list of lines (a line being a 2D array or list of 2-tuples), but every line is not required to be the same length. This would cause NumPy to produce an object array, but it will start to warn about ragged arrays in 1.19. An array isn't really needed as `Line3DCollection._segments3d` is only iterated over.
These inputs may be ragged, but we only just need to know the length of the items. There's no need to make an array to check that.
This is a raising a deprecation warning in NumPy 1.19, may go away some time later, and is not strictly necessary for the implementation.
This causes a NumPy deprecation warning if the list is ragged.
This function accepts almost anything list-like, so we really do want conversion to object arrays if the input is ragged. For example, this might occur for `scatter()` if passed different types of `colors`, like in the `test_scatter_marker` test.
|
Oh, hmmm, didn't notice that had a bunch of commits. Sorry if that was meant to be squashed... |
Prepare for ragged array warnings in NumPy 1.19
Conflicts:
lib/matplotlib/axes/_axes.py
- implicitly backported changes to wording in error messages
|
Do we want to backport this to 3.2.2? I tried cherry-picking and there is 12 failures on 3.2.x with this backported and numpy master. I guess our choices are :
I'm between 1 and 3. Doing it half way seems like a poor life choice and I am not sure that it is worth the effort for 3. |
|
At least for Fedora, this would not be a problem as they would not show up at the same time. We can possibly just say they aren't supported on other systems (mainly conda-forge, I'd assume). I tried the backport and there are about 11 extra failures. I believe that most of them are fixed by #15834, as that removes the |
|
Given that this caused a regression I am glad that we opted not to backport. |
PR Summary
NumPy 1.19 will issue a deprecation warning about ragged arrays numpy/numpy#15119, which causes our tests to fail as we fail on warning. This fixes the easy things, but there are 4 more classes of failures:
cbook._reshape_2D's test checking that a ragged array is turned into an object array. Fixes BUG: VisibleDeprecationWarning in boxplot #16353histcasting raggedxinput to a 2d array (most of the failures are this one)test_scatter_markerpasses an array of color-likes, which goes through_combine_maskswhich tries to cast as an array_combine_masksto use object array, or pass a flag to allow it? I'm not sure if it should always try to use an object array.test_bad_plot_argspasses some ridiculous values, and I don't know if they should be checked earlier or just allow it to fail when NumPy turns this into an errorI haven't just changed these to explicitly ask for object arrays because I haven't yet figured out what the implications are in NumPy and why they started warning.
PR Checklist