On Sun, Nov 8, 2009 at 1:26 PM, Brett Cannon <br...@python.org> wrote: > During the moratorium PEP discussions Guido said he wanted to quiet > down deprecation warnings. I see there being two options on this. > > One is to keep things as is, but to require two releases with > PendingDeprecationWarning so there are three years of > silent-by-default warnings to update your code. But that last release > before removal came would still be noisy. > > The other option is to simply have all warnings filtered out by > default. We could alter -W so that when it is used w/o an argument it > turns to what is currently the default behaviour (or even turn all > warnings which is more than what happens now). This will require that > people proactively check for warnings when updating for compatibility, > else they will eventually use a Python release where there code will > simply break because something changed. This route means we do not > have to specify any deprecation policy right now (that would be a > separate discussion). > > Channeling Guido he is after the latter, but a general discussion > would still be good since he didn't explicitly say what he was after > other than to quiet down warnings.
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. On Sun, Nov 8, 2009 at 1:35 PM, Michael Foord <mich...@voidspace.org.uk> wrote: > Almost no-one is ever going to run Python with PendingDeprecation > warnings switched on, so there should be at least one 'noisy' release in > my opinion. 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. (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.) -- --Guido van Rossum (python.org/~guido) _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
