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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4