[issue32229] Simplify hiding developer warnings in user facing applications

R. David Murray added the comment: Ah, OK, that makes more sense. I don't run into warnings other than DeprecationWarnings in practice, so I tend to forget about them :) I think specifying warnings filters is pretty inscrutable, in general. --

[issue32229] Simplify hiding developer warnings in user facing applications

Nick Coghlan added the comment: Note: for consistency with the underlying action names, the API should probably be called "warnings.ignore_warnings". I'd still keep the proposed parameter name as "show" though (and we may want to consider introducing that as a more

[issue32229] Simplify hiding developer warnings in user facing applications

Nick Coghlan added the comment: Warnings aren't off by default in general - we just add implicit "ignore" filters for a few specific types. So the primary functionality is to opt in to hiding *all* warnings, but to do it in a way that can be overridden by PYTHONWARNINGS,

[issue32229] Simplify hiding developer warnings in user facing applications

R. David Murray added the comment: I haven't been following that discussion, and isolated from that that discussion the title of this issue and this proposal make no sense to me. Warnings are off by default, so you don't need to hide them. In what context does this

[issue32229] Simplify hiding developer warnings in user facing applications

New submission from Nick Coghlan : One of the observations coming out of the PEP 565 discussions is that it's surprisingly tricky to opt-in to getting all warnings from a particular package and its subpackages, while opting out of warnings in general. The simplest