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

[Guido van Rossum]

[Laura]
>> Experience has shown that when people get used to seeing 'a bunch of
>> warnings that don't really matter' they either a) turn them off or
>> b) ignore them, even when they are telling them valuable things that
>> they should be paying attention to.  So constantly spitting out
>> DeprecationWarnings as soon as something becomes deprecated is a
>> most excellent way to train people to ignore DeprecationWarnings.

On Sun, Nov 8, 2009 at 10:39 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Well at least people get a chance to see them. If some people think the
> warnings are useless (even though the messages warn about removal of a
> construct), they won't run a code checker either.

You're misreading Laura. She's not saying that some people choose to
ignore the warnings. She's pointing out that it is a scientifically
known fact that people will *learn to ignore warnings* if they occur
frequently enough, and that once this is learned the warnings have no
effect. Look up Jef Raskin's diatribes against modal dialogs. (Or read
the "cry wolf" fairy tale. :-)

> If Mercurial users and developers hadn't seen those warnings at all,
> perhaps Mercurial would have continued using deprecated constructs, and
> ended up broken when the N+1 Python version had been released. If even
> an established FLOSS project such as Mercurial is vulnerable to this
> kind of risk, then any in-house or one-man project will be even more
> vulnerable.

If the Mercurial developers claimed that Mercurial supported Python
2.6 without extensive testing they would be rank amateurs. I don't
believe they are.

> Besides, do we have such a code checker that is able to find out
> deprecated constructs (not talking about 2to3 here) ?

At Google we use a hacked-up version of pylint which seems infinitely
flexible in the checks you can specify. I assume that the public
version of pylint is just as capable -- someone just needs to write a
rule for it.

-- 
--Guido van Rossum (python.org/~guido)