[Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Nick Coghlan ncoghlan at gmail.com
Sun Nov 5 22:38:59 EST 2017


On 6 November 2017 at 12:29, Oleg Broytman <phd at phdru.name> wrote:
> On Sun, Nov 05, 2017 at 09:20:12PM -0500, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>> Big +1 from me.  The whole point of DeprecationWarnings is to be
>> visible
>
>    The whole point of DeprecationWarnings is to be visible to
> developers while in reality they will be visible to users -- and what
> the users would do with the warnings?

Hence the proposed documentation change: the responsibility for
silencing these warnings (for both their own code and for their
dependencies) should rest with *application* developers, with our
responsibility as providers of the underlying platform then being to
make it completely obvious how to actually do that (it's currently
really unclear, with the relevant info being scattered across the list
of builtin warnings, different parts of the warnings module and
CPython command line usage documentation, with no explicit examples of
exactly what you need to write anywhere).

To put that another way:

- if we ever write "import foo" ourselves, then we're a Python
developer, and it's our responsibility to work out how to manage
DeprecationWarning when it gets raised by either our own code, or the
libraries and frameworks that we use
- if we ship Python code in a "supply your own runtime" model, such
that we have actual non-developer users and operators (rather than
solely fellow Python developers) to worry about, then it's still our
responsibility to decide whether or not we want to let deprecation
warnings appear on stderr (based on what we think is most appropriate
for our particular user base)
- if we want to categorically ensure our users don't get unexpected
deprecation warnings on stderr, then we should be bundling a Python
runtime as well (e.g. via PyInstaller or a Linux container image, or
by operating a network service), rather than asking users and
operators to handle the runtime+application integration step

We've been running the current experiment for 7 years, and the main
observable outcome has been folks getting surprised by breaking
changes in CPython releases, especially folks that primarily use
Python interactively (e.g. for data analysis), or as a scripting
engine (e.g. for systems administration).

That means the status quo is defeating the main purpose of
DeprecationWarnings (providing hard-to-miss advance notice of upcoming
breaking changes in the language definition and standard library), for
the sake of letting app developers duck responsibility for managing
what their own software writes to stderr.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list