[Python-Dev] Proposal: go back to enabling DeprecationWarning by default (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Sun Nov 5 22:38:59 EST 2017
- Previous message (by thread): [Python-Dev] Proposal: go back to enabling DeprecationWarning by default
- Next message (by thread): [Python-Dev] Proposal: go back to enabling DeprecationWarning by default
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] Proposal: go back to enabling DeprecationWarning by default
- Next message (by thread): [Python-Dev] Proposal: go back to enabling DeprecationWarning by default
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]