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 options. 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) - "show me all legacy calls" (the testing use case, needs to be a command line/environment setting) - "only show me legacy calls in *my* code" (the "I trust my deps to take care of themselves" use case) - "show me all legacy calls into a particular dependency" (the "I'm considering upgrading this" use case, handled by the warn module on PyPI) (Tangent: as indicated by my phrasing above, I'm wondering if "legacy calls"/"calls to legacy APIs" might be better user-centric terminology here, since those legacy calls are what we're actually trying to enable people to find and change - deprecation warnings are merely a tool designed to help serve that purpose) One of the biggest sources of tension is that silent-by-default is actually a good option when dependency upgrades are entirely in the hands of the application developer - if you're using something like pip-tools or pipenv to pin your dependencies to particular versions, and bundling a specific Python runtime with your application, and running your software through pre-merge CI, then "I am going to upgrade my dependencies now" is just another source code change, and your CI should pick up most major compatibility issues. In those scenarios, runtime deprecation warnings really are noise most of the time, since you already have a defined process for dealing with potential API breakages in dependencies. Where problems arise is when the decision on when to upgrade a dependency *isn't* in the hands of the application developer (e.g. folks using the system Python in a Linux distro, or an embedded Python scripting engine in a larger application). In those cases, the runtime deprecation warnings are important to notify users and maintainers that the next version upgrade for the underlying platform may break their code. This applies at higher levels, not just at the base Python platform layer. For example, if Fedora rebases matplotlib, then there's a chance that may require updating pitivi as well. Given that tension, it may be that this is an area where it makes sense for us to say "CPython uses [these warnings filters] by default, but redistributors may set the default warnings filter differently. Always use -W or PYTHONWARNINGS if you want to ensure a particular set of default filters are active." 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
