DeprecationWarnings: Transitioning from default silence in Python 3.7+

Warning Visibility and Noise Management

Starting with Python 3.7, DeprecationWarnings are ignored by default. This change was implemented to reduce notification noise for end-users, but it creates a visibility gap for developers who need to identify outdated API usage before a feature is fully removed in later versions.

Configuration Constraints

While the warnings module allows for fine-grained control via filterwarnings(), the global nature of the filter list means that elevating these warnings to errors or restoring their visibility can introduce significant noise across third-party dependencies. There is a tension between maintaining a clean production log and ensuring that critical migration paths are not overlooked.

Given that these warnings are now silenced by default in the interpreter, what is the recommended strategy for balancing noise suppression with the need for early migration alerts? Should DeprecationWarnings be treated as critical failures in CI/CD environments while remaining silenced in production, or is there a more surgical approach to target only internal project namespaces?