Nathaniel Smith added the comment:
> I still don't quite understand: what is the user-perceived result of this
> change? Module authors issuing a DeprecationWarning can now use stacklevel=2
> instead of stacklevel=10?
Exactly. There are a lot of deprecated modules in the wild, and the correct way
to mark a module as deprecated is by writing
warnings.warn("This module is deprecated!", stacklevel=2)
at the top-level of your module. Except that in Python 3.3 you have to use
stacklevel=10, and in Python 3.4 you have to use stacklevel=8, and I haven't
checked what you need in Python 3.5 but it may well be different again, because
it depends on internal implementation details of the import system. Fortunately
AFAICT from some code searches no-one is actually depending on this though;
instead everyone just writes stacklevel=2 and gets the wrong result.
(This is made more urgent b/c people are increasingly relying on the stacklevel
information to filter whether they even see the DeprecationWarning. E.g. I've
seen multiple test suites which register a warnings filter that displays
DeprecationWarnings iff they are attributed to the package-under-test, and
IPython now shows deprecation warnings by default if the warning is attributed
to interactive code -- see issue 24294. So there's a good chance that users
will only find out that the module they are using is deprecated if the
stacklevel= is set correctly.)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24305>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
