[Python-Dev] Proposal: go back to enabling DeprecationWarning by default (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Tue Nov 7 04:40:28 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 Tue, 7 Nov 2017 09:30:19 +0000 Paul Moore <p.f.moore at gmail.com> wrote:
I understand the "but no-one actually does this" argument. And I understand that breakage as a result is worse than a few warnings. But enabling deprecation warnings by default feels to me like favouring the developer over the end user.
I understand this characterization.
I'd prefer it if rather than simply switching warnings on by default, we worked on making it easier for the people in a position to actually fix the issue (coders writing programs, educators developing training materials, etc) to see the warnings. For example, encourage the various testing frameworks (unittest, pytest, nose, tox, ...) to enable warnings by default,
pytest does nowadays. That doesn't mean warnings get swiftly fixed, though. There are many reasons why (see my initial reply to Nick's proposal).
ensure that all new deprecations are documented in the "Porting to Python 3.x" notes, etc.
In my experience, Python deprecations are in the minority. Most often you have to deal with deprecations in third-party libraries rather than Python core/stdlib, because we (Python) are more reluctant to change and deprecate APIs than the average library maintainer is.
Regards
Antoine.
- 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 ]