Hey everyone,
In adding a deprecation warning in this pull request [1], Damon and I
learned that DeprecationWarnings are ignored by default in Python 2.7
This is rather unfortunate, and I outlined possible workarounds that I
see in a commend on that PR [2].
In trying to rectify this situation, I have created a
MatplotlibDeperecationWarning class that inherits from UserWarning,
which is *not* ignored by default. [3]
1. https://github.com/matplotlib/matplotlib/pull/1535
2. https://github.com/matplotlib/matplotlib/pull/1535#issuecomment-11061572
3. https://github.com/matplotlib/matplotlib/pull/1565
Any feedback is appreciated,
better,
···
--
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
If you're defining your own warning class, you might consider using
FutureWarning instead of UserWarning.
We had a discussion about this issue for numpy recently:
http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062460.html
What we eventually ended up with:
http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062468.html
-n
···
On Wed, Dec 5, 2012 at 9:45 PM, Paul Ivanov <pivanov314@...149...> wrote:
Hey everyone,
In adding a deprecation warning in this pull request [1], Damon and I
learned that DeprecationWarnings are ignored by default in Python 2.7
This is rather unfortunate, and I outlined possible workarounds that I
see in a commend on that PR [2].
In trying to rectify this situation, I have created a
MatplotlibDeperecationWarning class that inherits from UserWarning,
which is *not* ignored by default. [3]
1. Deprecate mpl.py (was Remove mpl.py) by ivanov · Pull Request #1535 · matplotlib/matplotlib · GitHub
2. Deprecate mpl.py (was Remove mpl.py) by ivanov · Pull Request #1535 · matplotlib/matplotlib · GitHub
3. new MatplotlibDeprecationWarning class by ivanov · Pull Request #1565 · matplotlib/matplotlib · GitHub
If you're defining your own warning class, you might consider using
FutureWarning instead of UserWarning.
We had a discussion about this issue for numpy recently:
http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062460.html
What we eventually ended up with:
http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062468.html
Thanks for the pointers, Nathaniel. Though I think I disagree with
continuing to use DeprecationWarnings for features that will go away
and just break code - shouldn't users be given ample opportunity of
coming changes without having to find out by having their code break
Using FutureWarning for deprecated functions (i.e. functions that will
disappear in future releases) is an abuse of the semantics.
FutureWarning is for things like the numpy.histogram() changes from a
few years ago: changes in default arguments that will change the
semantics of a given function call. Some of our DeprecationWarnings
possibly should be FutureWarnings, but most shouldn't I don't think.
then Nathaniel summarized:
If a function or similar will just disappear in a future release,
causing obvious failures in any code that depends on it, then
DeprecationWarning is fine. People's code will unexpectedly break from
time to time, but in safe ways, and anyway downgrading is easy.
- Otherwise FutureWarning is preferred
And most of our DeprecationWarnings *are* about code that will just
disappear in future releases.
···
On Wed, Dec 5, 2012 at 1:52 PM, Nathaniel Smith <njs@...503...> wrote:
at a future release? Robert Kern wrote:
--
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7>
Yeah, there aren't any perfect solutions here. That's why I didn't
express an opinion on what you ought to do :-).
Basically what the debate comes down to is, deprecation warnings are
useful to developers, and annoying and scary to users. (And users can
easily end up seeing them, e.g. if they use a package which depends on
matplotlib, and then upgrade matplotlib, their existing package may
suddenly start spewing scary warnings, and that package's developers
can't do anything about this because this version of matplotlib is
newer than anything that existed when they released their package.)
This problem becomes worse the lower your package is in the stack, and
the more widely used it is by third-party packages.
It's easier to tell developers how to turn on deprecation warnings
than it is to tell users how to turn them off, so that's why the
Python stdlib turned them off by default, and similarly numpy.
The main thing I took from this personally is that I went and added
'export PYTHONWARNINGS=default' to all my package's test scripts, to
ensure deprecation warnings would be enabled...
-n
···
On Wed, Dec 5, 2012 at 10:23 PM, Paul Ivanov <pivanov314@...149...> wrote:
On Wed, Dec 5, 2012 at 1:52 PM, Nathaniel Smith <njs@...503...> wrote:
If you're defining your own warning class, you might consider using
FutureWarning instead of UserWarning.
We had a discussion about this issue for numpy recently:
http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062460.html
What we eventually ended up with:
http://mail.scipy.org/pipermail/numpy-discussion/2012-May/062468.html
Thanks for the pointers, Nathaniel. Though I think I disagree with
continuing to use DeprecationWarnings for features that will go away
and just break code - shouldn't users be given ample opportunity of
coming changes without having to find out by having their code break
at a future release?