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

[Barry Warsaw]

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.

+1

> 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
> explicitly.

+1

> (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.)

Very +1

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/stdlib-sig/attachments/20091110/97077d85/attachment.pgp>