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

Laura Creighton lac at openend.se
Mon Nov 9 07:25:34 CET 2009

In a message of Mon, 09 Nov 2009 07:10:08 +0100, Antoine Pitrou writes:
>> 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.
>Well as I said this helps only if the package has 100% test coverage,
>such that the developer is sure to exercise all code paths when he/she
>runs the test suite with warnings explicitly enabled.
>Besides, as Yuvgoog pointed out, this would not help the casual hobbyist
>programmer (or professional non-programmer, such as a scientist) who
>doesn't really have a clue that those warnings exist and are important
>to check for.

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.

I appreciate the desire to help the casual programmer, but it is
not clear to me that this will turn out to actually be helpful.  Teaching
people to run their code through some sort of code-checker every
so often strikes me as more likely to be so.


More information about the stdlib-sig mailing list