[stdlib-sig] standardizing the deprecation policy (and how noisy they are)
barry at python.org
Tue Nov 10 15:41:32 CET 2009
On Nov 8, 2009, at 3:40 PM, Guido van Rossum wrote:
> I was specifically after all kinds of deprecation warnings, which
> generally are telling you that you need to make a change in order to
> remain compatible in the future. That's sometimes interesting but
> often irrelevant noise. So I would agree with Gregory P Smith's
> proposal to just treat all deprecation warnings as silent.
> There are other kinds warnings which might be useful for other reasons
> -- they typically point out code that does not do what you might think
> it does. A good example is the warning added in 2.6 about "assert (x,
> y)". This is something you ignore at your peril.
Yes, I was quite surprised at the few small example of this in
Launchpad. This was actually something I was glad to see warned
about, and of course we landed fixes for these independent of our
Python 2.6 migration work.
> I disagree. The -3 option is an example of a better approach: silent
> by default, warnings enabled by a command line flag. If we can trust
> developers to use -3 to check for Py3k incompatibilities, we should
> also be able to trust them to check for deprecation warnings
> (Another argument to think about: if you download and install some 3rd
> party code, deprecation warnings about that code are *only noise*
> since they are not yours to fix. Warnings in a dynamic language work
> very different than warnings in a compiled language.)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 194 bytes
Desc: This is a digitally signed message part
More information about the stdlib-sig