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/
