> On Nov 19, 2017, at 8:40 AM, Nathaniel Smith <njs at pobox.com> wrote: > > We have been using DeprecationWarning for changes where code will > transition from working -> raising an error, and that *is* based on > the Official Recommendation to hide those by default whenever > possible. We've been doing this for a few years now, and I'd say our > experience so far has been... poor. I'm trying to figure out how to > say this politely. Basically it doesn't work at all. What happens in > practice is that we issue a DeprecationWarning for a year, mostly > no-one notices, then we make the change in a 1.x.0 release, everyone's > code breaks, we roll it back in 1.x.1, and then possibly repeat > several times in 1.(x+1).0 and 1.(x+2).0 until enough people have > updated their code that the screams die down. I'm pretty sure we'll be > changing our policy at some point, possibly to always use > FutureWarning for everything. In pip we ended up working around the not-displaying-by-default so that we got the old behavior back again because hiding warnings doesn’t work great in my experience. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171129/e0303f40/attachment.html>
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