On Sun, Nov 8, 2009 at 13:40, Guido van Rossum <gu...@python.org> wrote: > 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. >
There is also the argument that if people are told they have to explicitly turn on warnings to get them and the switch turns them all on then it might be the case that more people will see and deal with PendingDeprecationWarnings than they do now. The arguments that people will not switch them on is based on current practice. Guido's and Greg's argument is that habits will change such that it is not going to be an issue. What does this mean for the warning filter? It will obviously tone down its need, but would it be needed at all? If warnings are off by default the need to actively filter them out goes down by a lot. And you probably don't want to accidentally filter out a warning if you have to explicitly turn them on. I would argue that if you have to explicitly turn filters on then you don't have much of a need to selectively silence them and thus the filter can just go away. > (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.) That's very true. Until Mercurial caught up to Python 2.6 the sha/md5 warnings were very annoying. I actually modified my copy to turn them off myself. -Brett _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
