[Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

[Nick Coghlan]

On 7 November 2017 at 05:00, Alex Gaynor <alex.gaynor at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia