On Feb 25, 2015 2:58 AM, "Paul Moore" <firstname.lastname@example.org> wrote:
> On 25 February 2015 at 10:35, Chris Angelico <email@example.com> 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.
Warnings have both a type (DeprecationWarning) and a source (line 37 of module X), with the idea being that the source is supposed to point to the code that's doing something questionable (which generally isn't the code that called warnings.warn). It would be totally possible to enable display of only those DeprecationWarnings that are attributed to stuff typed in at the REPL.
And it sounds like a great idea to me.
(NB that if we do this we'll run into another annoying problem with warnings and the REPL, which is that every line typed in the REPL is "line 1", so generally any given warning will only be produced once even if the offending behavior occurs in multiple different statements. This tends to really confuse users, since it means you can't use trial and error to figure out what was wrong with your code: whatever tweak you try first will always appear to fix the problem. Some more discussion of this issue here: https://github.com/ipython/ipython/pull/6680)