Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

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

Merged
merged 5 commits into from
Jan 29, 2017
Merged

Fix/hide some deprecations #7857

merged 5 commits into from
Jan 29, 2017

Conversation

QuLogic
Copy link
Member

@QuLogic QuLogic commented Jan 17, 2017

I found the first commit lying around on disk, so better get it merged sometime.

@@ -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
Copy link
Contributor

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.)

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Member

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).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True.

Copy link
Member Author

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.

Copy link
Contributor

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))

Copy link
Member Author

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:
Copy link
Member

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?

Copy link
Contributor

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, fair enough.

@tacaswell tacaswell added this to the 2.1 (next point release) milestone Jan 17, 2017
@QuLogic QuLogic changed the title Fix/hide some deprecations [MRG] Fix/hide some deprecations Jan 20, 2017
@QuLogic QuLogic changed the title [MRG] Fix/hide some deprecations Fix/hide some deprecations Jan 21, 2017
@QuLogic
Copy link
Member Author

QuLogic commented Jan 21, 2017

There seems to be a bug with the spectral deprecation warning; it's not triggered after the production of the reversed version in cm.py on Python 2.7, only.

@QuLogic
Copy link
Member Author

QuLogic commented Jan 21, 2017

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.

@QuLogic QuLogic changed the title Fix/hide some deprecations [MRG] Fix/hide some deprecations Jan 21, 2017
@QuLogic
Copy link
Member Author

QuLogic commented Jan 22, 2017

Rebased due to conflicts.

@NelleV
Copy link
Member

NelleV commented Jan 22, 2017

I just want to make sure I understand your last comment.
If we include this patch, users won't see the spectral warning anymore, or without this patch, they don't see the deprecation warning?

@QuLogic
Copy link
Member Author

QuLogic commented Jan 22, 2017

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>
>>> 

@QuLogic
Copy link
Member Author

QuLogic commented Jan 22, 2017

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)
Copy link
Contributor

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):
Copy link
Contributor

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).

Copy link
Member Author

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).
@anntzer anntzer changed the title [MRG] Fix/hide some deprecations [MRG+1] Fix/hide some deprecations Jan 28, 2017
@NelleV NelleV merged commit 0ce413f into matplotlib:master Jan 29, 2017
NelleV added a commit that referenced this pull request Jan 29, 2017
Backport spectral/spectral_r deprecations fixes from #7857
@QuLogic QuLogic deleted the deprecations branch January 31, 2017 09:03
@QuLogic QuLogic changed the title [MRG+1] Fix/hide some deprecations Fix/hide some deprecations Jan 31, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.