On Tue, May 30, 2017 at 6:41 AM RonnyPfannschmidt < [email protected]> wrote:
> > > I'd still be in favour of turning them on by default, if that's possible > > without clashing with existing filters. I don't think it's the job of > > libraries to modify warning filters - they already do do decide to show > > those warnings, otherwise they wouldn't emit them in the first place. > > > > Other test runners already show them. There's even some discussion about > > showing them by default in the REPL, and ipython already seems to do > > that: > > http://bugs.python.org/issue24294 > > https://github.com/ipython/ipython/issues/8478 > > > > If we don't show them, nobody will see them, and they won't be fixed > > before stuff breaks for real. I've reported so many bugs to libraries > > which used deprecated stuff - they didn't see the warnings because they > > were using pytest with the default settings, and I did because I was > > using pytest-warnings. But things shouldn't be that way. > > py.test should enable its own warnings so people see them > py.test is the "library", so py.test enables the filters > I agree with Florian that pytest should strive to generate deprecation warnings by default for the reasons he mentions, but I think if we are going to do it we should do it slowly and in careful steps. As a testing framework we just learned that it is easy to mess up with the warnings filters and break test suites which configure their own filters. I don't see an easy way to introduce this with the builtin warning filters without risking breaking existing suites, so we would have to figure a different way to implement it (monkey patching comes to mind). To introduce it we should add an option to enable the feature in a minor release, defaulting to False, and then perhaps consider turning it on by default in a major version. That's my 2 cents at least. Cheers, Bruno.
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
