On 6 November 2017 at 14:14, Barry Warsaw <ba...@python.org> wrote: > On Nov 5, 2017, at 18:05, Nick Coghlan <ncogh...@gmail.com> 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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com