Hi, In this case, we need more advanced warnings filters to only show deprecation warnings in the "current application code", and ignore deprecation warnings from any other module. Is there a way to create an entry point in setuptools which says "this application uses the package xxx"?
Since there is no simple solution to this problem and it was decided to hide warnings by default, I added an explicit "Python Development Mode" to Python 3.7 which shows warnings, but also enables some expensive runtime debug checks. https://docs.python.org/dev/library/devmode.html "The Python Development Mode introduces additional runtime checks that are too expensive to be enabled by default. It should not be more verbose than the default if the code is correct; new warnings are only emitted when an issue is detected." I suggest running your test suite using "python -X dev -Werror" command line, or PYTHONDEVMODE=1 and PYTHONWARNINGS=error environment variables. It's possible to ignore warnings from third party projects using warnings filters. I put this suggestion at the start of the What's New in Python 3.9 document: https://docs.python.org/dev/whatsnew/3.9.html#you-should-check-for-deprecationwarning-in-your-code Should we put such suggestion elsewhere? Or repeat it in each What's New in Python X.Y document? Victor On Wed, Apr 21, 2021 at 1:14 PM Paul Moore <p.f.mo...@gmail.com> wrote: > > On Wed, 21 Apr 2021 at 12:05, M.-A. Lemburg <m...@egenix.com> wrote: > > > Perhaps we should reconsider making deprecation warnings only > > visible by explicitly enabling them and instead make them visible > > by default. > > > > This would create more noise for users, but for the better, since > > planned changes then become more visible and can be addressed > > either by silencing the warning (and opening a ticket to get > > the change addressed) or by fixing the code in a new release. > > We've tried this in the past, and the problem is that it hits the > wrong people. Users typically can't do anything directly about the > warnings, other than report them to the offending packages. So the > person hit by the warning then has an indefinite wait while the > upstream package fixes the issue (either fully, or just by temporarily > suppressing the warning) and releases a new version (which depending > on the project release cycles and processes, may not be a > straightforward replacement for the previous version). > > > If package authors were to get into the habit of doing the > > silencing for their users after opening a ticket, that would > > probably make the whole process more streamlined and effective. > > If that was what actually happened, then maybe this would work. But > unfortunately this is open source, and many projects haven't got the > resources to make emergency releases to silence a warning for their > users. > > Paul > _______________________________________________ > python-committers mailing list -- python-committers@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committers@python.org/message/XYLETQTARRX32IYQXPKSGNLC57OMCE22/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/Q2IFJ3F2QSXZUZP7FUKH7MKPNWF66MHN/ Code of Conduct: https://www.python.org/psf/codeofconduct/
