On Sun, Nov 19, 2017 at 5:40 AM, Nathaniel Smith <n...@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
