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

[Terry Reedy]

On 11/6/2017 9:47 PM, Nick Coghlan wrote:
> 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 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