This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author njs
Recipients Arfrever, barry, berker.peksag, brett.cannon, eric.snow, ncoghlan, njs, serhiy.storchaka, takluyver
Date 2015-05-30.06:10:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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:

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
    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.
Date User Action Args
2015-05-30 06:10:31njssetrecipients: + njs, barry, brett.cannon, ncoghlan, Arfrever, eric.snow, takluyver, berker.peksag, serhiy.storchaka
2015-05-30 06:10:31njssetmessageid: <>
2015-05-30 06:10:31njslinkissue24305 messages
2015-05-30 06:10:30njscreate