On 11/6/2017 9:47 PM, Nick Coghlan wrote:
On 7 November 2017 at 05:00, Alex Gaynor <alex.gay...@gmail.com> wrote:
I also feel this decision was a mistake. If there's a consensus to revert,
I'm happy to draft a PEP.
Even without consensus to revert, I think it would be great to have a
PEP summarising some of the trade-offs between the different optio
I hope that there is consensus that neither the old nor current default
is necessarily the best we can do.
And I do think there's openness to improving the situation, it's just
not clear yet that simple reversion of the previous change is the
right approach to attaining that improvement. In particular, the point
Georg Brandl raised about the poor interaction between the "-W"
command line option and Python code that calls
"warnings.filterwarnings" is still valid, and still a cause for
concern (whereby if code disables deprecation warnings, there's no
command line option or environment variable that can be used to
override that setting and force all the warnings to be shown despite
what the code says).
More generally, we seem to have (at least) 4 different usage models desired:
- "show my users nothing about legacy calls" (the app dev with a user
provided Python use case)
I believe that this is the current default. But in practice, it often
also means 'show the developer nothing about legacy calls', and therein
lies the problem with the current default.
- "show me all legacy calls" (the testing use case, needs to be a
command line/environment setting)
I believe that this was the old default. And I understand that it is
the default when running the CPython test suite. For testing the
stdlib, it works because we control all the dependencies of each module.
But for other apps, the problem for both users and developers being
overwhelmed with warnings from sources not in one's control.
- "only show me legacy calls in *my* code" (the "I trust my deps to
take care of themselves" use case)
Perhaps this should be the new default, where 'my code' means everything
under the directory containing the startup file. If an app developer
either fixes or suppresses warnings from app code when they first
appear, then users will seldom or never see warnings. So for users,
this would then be close to the current default.
Even for unmaintained code, the noise should be someone limited in most
cases.
- "show me all legacy calls into a particular dependency" (the "I'm
considering upgrading this" use case, handled by the warn module on
PyPI)
--
Terry Jan Reedy
_______________________________________________
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
