-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Fix/hide some deprecations #7857
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -190,7 +190,7 @@ def set_longitude_grid(self, degrees): | ||
""" | ||
Set the number of degrees between each longitude grid. | ||
""" | ||
number = (360.0 / degrees) + 1 | ||
number = int(360.0 / degrees) + 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
360 / degrees
, no need for .0
anymore (... especially given that you're casting to int immediately after). Same below.
Also I have no knowledge about this part of the code but are you sure it's shouldn't be math.ceil(360/degrees)
? (Just guessing.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I don't think this line is correct. It should probably be number = int(np.round(360 / degrees))
. Right now, if degrees = 360, then number is equal to 2, which I am pretty sure is wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Builtin round should be enough, then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do NOT use built-in round, that introduces differences between Python 2 and 3. Use numpy's.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should always use numpy stuff when we can. We depend on numpy, so there is no reason to not use it (unless I am missing something).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand; if degrees = 360, it's a nice round division, so it doesn't matter if you use ceil
, round
, or plain int
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the confusion was whether it's working correctly. I'm not sure what rounding behavior we want, but the + 1
is needed to work with the call to linspace below, since we're removing the first and last points. Would probably make more sense as:
number = np.round(360 / degrees)
ticks = np.linspace(-nppi, np.pi, number, endpoint=False)[1:]
self.axis.set_major_locator(FixedLocator(ticks))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rewrote these cases in a way that I hope makes it clearer.
@@ -211,7 +211,7 @@ def convert(filename, cache): | ||
verifiers = {} | ||
|
||
# Turning this off, because it seems to cause multiprocessing issues | ||
if matplotlib.checkdep_xmllint() and False: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iirc @anntzer deletes this in another PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I deprecated it, so during the deprecation period the "False" should indeed come first to avoid triggering a deprecation warning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, fair enough.
There seems to be a bug with the |
That last commit should fix the warning on 2.7; not sure if we should backport it as at the moment, users on 2.7 don't see the warning they're supposed to. |
Rebased due to conflicts. |
I just want to make sure I understand your last comment. |
Without the last commit, on Python 2.7, users don't see the deprecation warning: $ python
Python 2.7.12 (default, Sep 29 2016, 12:52:02)
[GCC 6.2.1 20160916 (Red Hat 6.2.1-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib
>>> matplotlib.__version__
'2.0.0'
>>> import matplotlib.pyplot as plt
>>> plt.get_cmap('spectral')
<matplotlib.colors.LinearSegmentedColormap object at 0x7f61bfd5f0d0>
$ python3
Python 3.5.2 (default, Sep 14 2016, 11:28:32)
[GCC 6.2.1 20160901 (Red Hat 6.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib
>>> matplotlib.__version__
'2.0.0'
>>> import matplotlib.pyplot as plt
>>> plt.get_cmap('spectral')
/usr/lib64/python3.5/site-packages/matplotlib/cbook.py:136: MatplotlibDeprecationWarning: The spectral and spectral_r colormap was deprecated in version 2.0. Use nipy_spectral and nipy_spectral_r instead.
warnings.warn(message, mplDeprecation, stacklevel=1)
<matplotlib.colors.LinearSegmentedColormap object at 0x7f985bbc89e8>
>>> |
Oh, and to be clear, the second commit hides the warning when running tests only. I'm only wondering about backporting the last commit and not the entire PR. |
@@ -97,7 +97,7 @@ def test_make_compound_path_empty(): | ||
def test_xkcd(): | ||
np.random.seed(0) | ||
|
||
x = np.linspace(0, 2.0 * np.pi, 100.0) | ||
x = np.linspace(0, 2.0 * np.pi, 100) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2.0 -> 2 (now that we're there...)
@@ -83,8 +83,9 @@ def _generate_cmap(name, lutsize): | ||
|
||
# We silence warnings here to avoid raising the deprecation warning for | ||
# spectral/spectral_r when this module is imported. | ||
with _warnings.catch_warnings(): | ||
with _warnings.catch_warnings(record=True): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems way too complicated. I would just invoke getitem using the superclass method, i.e. use dict.__getitem__(cmap_d, name)
instead of cmap_d[name]
at the right place. (The first form does not raise a warning).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good idea and really simplifies things.
This fixes "DeprecationWarning: object of type <class 'float'> cannot be safely interpreted as an integer." raised by latest NumPy.
Do the calculation in degrees instead of trying to "optimize" the calculation in radians.
In 2.7, the hidden __warningregistry__ gets set and then the warning is never seen again, regardless of the filter setting. Instead, just never trigger the warning in the first place (thanks @anntzer).
Backport spectral/spectral_r deprecations fixes from #7857
I found the first commit lying around on disk, so better get it merged sometime.