On 25 February 2015 at 10:35, Chris Angelico firstname.lastname@example.org wrote:
On the other hand, what if "import <3rd party module>" flags a deprecation warning because of something the module author does? Certainly I can just ignore it (as it's "only" a warning) but it would get annoying pretty fast if I couldn't suppress it...
That might be a good excuse to lean on the module's author or submit a patch. :) But yes, that does present a problem, especially since warnings will, by default, show only once (if I'm understanding the docs correctly) - you ignore it in the import, and it's suppressed for the rest of the session.
The important point here is that the idea behind this proposal is that enabling deprecation warnings in the REPL is viable because the warnings will be referring to your code, and therefore you can choose whether or not to deal with them there and then. But 3rd party modules are a case where that isn't the case.
Deprecation warnings were hidden by default in the first place because the people who were affected by them were typically not the people who controlled the code triggering them. I don't think just showing them in the REPL alters that much.
Maybe the right solution is for testing frameworks (unittest, nose, py.test) to force deprecation warnings on. Then developers will be told about deprecation issues when they run their tests.