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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ stdlib-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/stdlib-sig
