| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Do you want to get these is as-is and address the rest later or hold these to fix them all in one shot? |
Sorry, something went wrong.
|
Ah, telling _reshape_2D to use object dtype breaks violinplot instead... |
Sorry, something went wrong.
|
This is mostly done, except for test_bad_plot_args, and I'm not sure what to do there. That test does: 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 ValueError. Unlike the other inputs, which raise in _plot_args, this one actually works fine, and raises somewhere deep in Line2D basically trying to draw. I think this case should have been caught in _plot_args, but I'm not sure how to check it safely. |
Sorry, something went wrong.
|
Not sure if that's the best last commit, but that should fix all the warnings. |
Sorry, something went wrong.
|
I pushed a commit to fix test_violinplot_pandas_series[png] that was failing for me locally. |
Sorry, something went wrong.
|
Do we want to backport this to 3.2.x? |
Sorry, something went wrong.
| 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?
Sorry, something went wrong.
There was a problem hiding this comment.
I assume it'll be a ValueError, but it wasn't clear in the NEP.
Sorry, something went wrong.
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... |
Sorry, something went wrong.
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. |
Sorry, something went wrong.
|
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 np.array call, but I have not tested it out, as I'm not sure we want to actually backport that. |
Sorry, something went wrong.
|
Given that this caused a regression I am glad that we opted not to backport. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
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:
I 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