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 Aaron.Meurer
Recipients Aaron.Meurer, Jim.Jewett, The Compiler, ezio.melotti, jayvdb, martin.panter, mbussonn, ncoghlan, njs, r.david.murray, rbcollins, serhiy.storchaka, takluyver, terry.reedy, vstinner
Date 2017-11-14.02:39:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
If it's of any interest to this discussion, for SymPy (for some time) we have used a custom subclass of DeprecationWarning that we enable by default I don't know if there are major libraries that do something similar. 

Our reasoning is that we really do want everybody to see the warnings. Obviously direct users of SymPy (both interactive users and library developers) need to see them so they can fix their code. But also if library X uses a deprecated behavior and a user of library X sees a deprecation warning for SymPy inside of library X, that incentivises them to bug the library X developers to fix the behavior (or PR it). The whole point of warnings as we see it is to be as loud as possible while still keeping things working, to avoid the situation where things stop working (when the deprecated behavior is removed). 

And +<however many points I'm allowed to have> to Nathaniel's point that DeprecationWarnings are about more than just the standard library. Tons of libraries use the built in warnings, and the default warnings behavior makes no distinction between warnings coming from the standard library and warnings coming from other places.
Date User Action Args
2017-11-14 02:39:24Aaron.Meurersetrecipients: + Aaron.Meurer, terry.reedy, ncoghlan, vstinner, rbcollins, ezio.melotti, r.david.murray, njs, takluyver, martin.panter, Jim.Jewett, serhiy.storchaka, The Compiler, jayvdb, mbussonn
2017-11-14 02:39:24Aaron.Meurersetmessageid: <>
2017-11-14 02:39:24Aaron.Meurerlinkissue24294 messages
2017-11-14 02:39:23Aaron.Meurercreate