On Tue, May 11, 2021 at 5:30 PM Petr Viktorin wrote:

Test tools should treat DeprecationWarning as error by default [0][1]. So even if end users don't really see it, I don't consider it "hidden".

*should* is not *do*. For example, nosetests don't show DeprecationWarning. And there are many scripts without tests. So it is hidden for some people. -- Inada Naoki

On Tue, 11 May 2021, 7:57 pm Petr Viktorin, wrote:

On 11. 05. 21 11:08, Inada Naoki wrote:

...

On Tue, May 11, 2021 at 5:30 PM Petr Viktorin wrote:

...

Test tools should treat DeprecationWarning as error by default [0][1]. So even if end users don't really see it, I don't consider it "hidden".

*should* is not *do*. For example, nosetests don't show DeprecationWarning. And there are many scripts without tests.

So it is hidden for some people.

Sadly, there's not much we can do for users of nose. Nose itself is only tested with Python 3.5 and below.

I'm aware that there are scripts without tests. But maybe letting them suddenly break is the right balance between letting people know and annyoing everyone with unactionable warnings.

Scripts (with or without tests) have gone back to showing deprecation warnings by default since 3.7: https://www.python.org/dev/peps/pep-0565/ If DeprecationWarning is not enough, then we should be having a wider

discussion, and PEP 387 should change. This particular issue should not be an exception to the process.

The limitations section of PEP 565 covers several known problems even with the 3.7+ status quo: https://www.python.org/dev/peps/pep-0565/#limitations-on-pep-scope Most notably, unit test doesn't catch import time or compile time deprecation warnings, and it doesn't catch deprecations in subprocesses. Another case that came up in this thread was support libraries that are tested with warnings treated as errors, but: * the test runner still doesn't enable all warnings (e.g. nose projects that never migrated to nose2) * the project isn't covered as a dependency by any *other* project's test suites that are stricter about avoiding deprecation warnings in their code and the code they use And, of course, projects that don't treat warnings as errors in their tests will get a green tick from CI systems no matter how many warnings they emit. If we wanted to go back to enabling DeprecationWarning by default across the board, I think we could only reasonably do that if we provided an easier to use "hide all warnings except the ones I specifically opt in to seeing" API like the one mentioned at the end of PEP 565: https://bugs.python.org/issue32229 As currently written, that API proposal would flip the ergonomics problem though - while ensuring the warnings system was configured early enough to capture compile time and import time warnings would be up to the application, being able to easily propagate the config change to subprocesses would need to be part of the new API design. Cheers, Nick.