On 6 November 2017 at 14:14, Barry Warsaw
On Nov 5, 2017, at 18:05, Nick Coghlan
wrote: So my proposal is simple (and not really new): let's revert back to the way things were in 2.6 and earlier, with DeprecationWarning being visible by default
+1
As part of this though, I'd suggest amending the documentation for DeprecationWarning [1] to specifically cover how to turn it off programmatically (`warnings.simplefilter("ignore", DeprecationWarning)`), at the command line (`python -W ignore::DeprecationWarning ...`), and via the environment (`PYTHONWARNINGS=ignore::DeprecationWarning`).
+1
I’d also consider adding convenient shortcuts for each of these. I think DeprecationWarning is special enough to warrant it. Possibly:
warnings.silence_deprecations() python -X silence-deprecations PYTHONSILENCEDEPRECATIONS=x
It could be interesting to combine this with Tim's suggestion of putting an upper version limit on the silencing, so the above may look like: warnings.ignore_deprecations((3, 7)) python -X ignore-deprecations=3.7 PYTHONIGNOREDEPRECATIONS=3.7 (Using "ignore" to match the existing action name so the intent is a bit more self-explanatory) The ignore_deprecations function would then look like: def ignore_deprecations(max_version): """Ignore DeprecationWarning on Python versions up to & including the given one *max_version* is an iterable suitable for ordered comparison against sys.version_info """ if sys.version_info <= max_version: warnings.simplefilter('ignore', DeprecationWarning) So the conventional usage would be that if you were regularly updating your application, by the time Python 3.8 actually existed, the check would have been bumped to say 3.8. But if you stopped updating (or the publisher stopped releasing updates), you'd eventually start getting deprecation warnings again as the underlying Python version changed. I could definitely see that working well for the community Linux distro use case, where there isn't necessarily anyone closely monitoring old packages to ensure they're actively tracking upstream releases (and attempting to institute more ruthless pruning processes can lead to potentially undesirable community dynamics) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia