Nathaniel Smith added the comment:
A nice new API is certainly a nice thing, but I feel that changing the stack
walking code should be considered as fixing a regression introduced in 3.3.
Indeed, searching github for code that actually uses the stacklevel= argument:
https://github.com/search?p=2&q=warnings.warn+DeprecationWarning+stacklevel&ref=searchresults&type=Code&utf8=%E2%9C%93
I observe that:
- there isn't a single usage on the first ten pages with stacklevel > 3, so
stack walking speed is unlikely to be an issue -- esp. since it will only be
slow in the cases where there are spurious import frames on the stack, i.e.,
you can only make it faster by making the results incorrect, and
- in the first ten pages I counted 14 distinct pieces of code (GH search is
chock full of duplicates, sigh), and *11* of them are specifically module
deprecations that are correctly passing stacklevel=2, and thus working on 2.7
but broken on 3.3+, and
- I counted zero examples where someone wrote
if sys.version_info[:2] == (3, 3):
stacklevel = 10
elif sys.version_info[:2] == (3, 4):
stacklevel = 8
else:
stacklevel = 2
warnings.warn("{} is deprecated".format(__name__), DeprecationWarning,
stacklevel=stacklevel)
which is the only situation where even backporting a fix for this would break
code that previously worked correctly.
Basically the overwhelming majority of uses of the stacklevel= argument are
broken in 3.3 and 3.4 and 3.5-beta. We should fix it.
----------
_______________________________________
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
