On Sun, Nov 19, 2017 at 5:40 AM, Nathaniel Smith <njs at pobox.com> wrote: > Eh, numpy does use FutureWarning for changes where the same code will > transition from doing one thing to doing something else without > passing through a state where it raises an error. But that decision > was based on FutureWarning being shown to users by default, not > because it matches the nominal purpose :-). IIRC I proposed this > policy for NumPy in the first place, and I still don't even know if it > matches the original intent because the docs are so vague. "Will > change behavior in the future" describes every case where you might > consider using FutureWarning *or* DeprecationWarning, right? > > 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. Can one of you check that the latest version of PEP 565 gets this right? -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171128/bfce21c3/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