[stdlib-sig] standardizing the deprecation policy (and how noisy they are)

[Yuval Greenfield]

On Tue, Nov 10, 2009 at 5:31 AM, Guido van Rossum <guido at python.org> wrote:
[snip]
> In the balance, I think it's easy enough to find these things by using
> the version that actually breaks things. If you are your only
> customer, until then, there's little benefit in fixing the warnings
> ahead of time (except perhaps for learning -- but, strangely, there
> are ways of learning about programming besides trying things out :-).
> If you have other customers, you should get used to testing with the
> latest version of Python anyway -- running without warnings in a
> previous version really isn't a good enough test for future
> compatibility.
>
> --
> --Guido van Rossum (python.org/~guido)
>

Yeah, it's easy to find and fix the bugs using the version that incurs
them. I'm not worried about that, I'm more worried about how
information will spread, a lot of pythonistas I know won't learn about
deprecations until their program is broken. Deprecation warnings
spread the word more elegantly and faster than hard deprecations IMO.

I guess an upside to silent warnings would be that we could have a lot
more of them. It could be nice if pylint was integrated as a warning
level, lets say with 2 popular conventions in the std-lib. I
personally always maximize the warning level on my C compiler and I
like the insight.

--yuv