new MatplotlibDeprecationWarning class (against 1.2.x)#1596
new MatplotlibDeprecationWarning class (against 1.2.x)#1596mdboom merged 2 commits intomatplotlib:v1.2.xfrom
Conversation
In light of the fact that Python builtin DeprecationWarnings are ignored by default as of Python 2.7 (see link below), this class was put in to allow for the signaling of deprecation, but via UserWarnings which are not ignored by default. http://docs.python.org/dev/whatsnew/2.7.html#the-future-for-python-2-x Prior to this commit: ``` In [1]: %pylab Welcome to pylab, a matplotlib-based Python environment [backend: agg]. For more information, type 'help(pylab)'. In [2]: mlab.liaupunov([1,2], np.diff) Out[2]: 0.0 ``` After this commit: ``` In [1]: %pylab Welcome to pylab, a matplotlib-based Python environment [backend: agg]. For more information, type 'help(pylab)'. In [2]: mlab.liaupunov([1,2], np.diff) /home/pi/.local/lib/python2.7/site-packages/matplotlib/mlab.py:1212: MatplotlibDeprecationWarning: This does not belong in matplotlib and will be removed mDeprecation) # 2009/06/13 Out[2]: 0.0 ```
|
This gets my +1. @NelleV Do you see any PEP8 issues that need to be addressed here? |
There was a problem hiding this comment.
I'm not a fan of renaming the variable here -- it makes it less clear what's happening in the lines below.
There was a problem hiding this comment.
Perhaps something a little more verbose? mplDeprecationWarning?
There was a problem hiding this comment.
Does just mplDeprecation seem ok? The reason is that it's either being used in code like warnings.warn("message", mplDeprecationWarning) and we then have the word warn written three times on one line, but there are other places where this class is being raised as an exception, so it's not just being used to warn, but actually to throw an error.
I was using mDeprecation because I thought we have that as a convention for prepending an m for matplotlib internal imports (axes.py, axis.py, collections.py and contour.py utilize this for matplotlib module imports)
There was a problem hiding this comment.
Yes, but in those cases, the m stands for module, which was the source of my confusion about this, at least. I think mplDeprecation would be fine and is a reasonable compromise.
There was a problem hiding this comment.
mplDeprecation is fine by me!
|
This looks OK from a pep8 point of view |
|
ok, updated to |
|
@ivanov Good job! +1. I think this should be merged now, and I think we should start time-lining a 1.2.1 release. |
new MatplotlibDeprecationWarning class (against 1.2.x)
Here's the promised rebase of #1565 onto the maintenance branch, with some whitespace fixes suggested there squashed into the commit here.
In light of the fact that Python builtin DeprecationWarnings are ignored
by default as of Python 2.7 (see link below), this class was put in to
allow for the signaling of deprecation, but via UserWarnings which are
not ignored by default.
http://docs.python.org/dev/whatsnew/2.7.html#the-future-for-python-2-x
Prior to this commit:
After this commit: