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

[Laura Creighton]

In a message of Mon, 09 Nov 2009 18:14:07 EST, geremy condra writes:
>On Mon, Nov 9, 2009 at 6:09 PM, Raymond Hettinger <python at rcn.com> wrote:
>>
>> [Brett Cannon]
>>>
>>> This is obviously coming down to difference of opinion. I don't view
>>> switching warnings off by default as shooting anyone in the foot. I
>>> put it on the same level as making sure you have unit tests; it's just
>>> part of your testing and verification process that your users just
>>> don't need to know about.
>>
>> Nice summary.  FWIW, I concur with Brett.  No one needs to see
>> warnings/deprecations except for the developer who controls the code.
>> Even that developer may only need to see it at one point during the
>> development process.  Further, the developer controlling the code
>> just may not care -- the script can be for single use, for a class proj
>ect,
>> or some other purpose that doesn't require being notified of what may
>> change in a later version of Python.
>>
>>
>> Raymond
>
>If they don't care, why does it matter whether they see it or not?
>Seems like an argument for the status quo.
>
>Geremy Condra

The reason that it matters is that having seen it a few times may make
it impossible for them to see it in the future.

We studied precisely this in determining 'how often should C
programmers run lint' back in the 1980s for DCIEM (The Canadian
department of War).  I started out as a firm proponent of 'you should
run lint every time' and 'you should fix your lint errors as soon as
you see them'.  It turned out that this was the wrong idea.  Most
people were completely unable to fix their lint errors as they showed
up.  They were unable to _see_ their lint errors as they showed up.
Because they were concentrating on the code that they were writing,
all errors and warnings about code that wasn't the focus of their
concentration didn't register with them consciously.  They were blind
to these errors and warnings because their concentration was somewhere
else.

Which wouldn't be so bad if, once they stopped concentrating on the
code they were writing, they were then free to see the lint errors
again, and fix them then.  But a very strange thing had happened by
that point.  They had become used to the lint errors that they weren't
paying attention to, and so they _still_ couldn't see them, even when
they wanted to, because they were habituated to them.  It was
striking.  You could ask the people to read their lint output, looking
for 'Warning: long assignment may lose accuracy' messages, and they
would read right by that message, and say, no, they didn't have one.
You could get them to read all of their lint messages, out loud, to
the whole room, and they would read them one by one, including the one
that said 'Warning: long assignment may lose accuracy' and go on to
the next message and _still_ not notice that they had found what you
had asked them to look for.

These are people who are most sincere in looking for these errors,
those who dearly wanted to fix them at this point in time.  But 
the development process that they had at this time destroyed their
ability to make use of the warnings that lint was giving them.  To
use lint well, they needed to use it _only_ when they were at a
point in their thinking when they were receptive to seeing such
messages.

(And, given that we were giving the poor bastards problems in 
string manipulation, which they all had to do with C pointer 
arithmetic, and that many of the soldiers were sticking with
ed, the editor they knew, rather than newfangled things such
as emacs, and the HCR screen editor -- this was before vi,
they had one heck of a lot to keep in their heads when they
were programming.  Lots of the time they were not receptive to
seeing any warnings at all.)

What we concluded was that people should only run lint on their
C programs when they wanted to fix those errors lint found.  While they
were busy concentrating on other things, they shouldn't run it.  And
it is bad to warn people unless you already have their attention, and
they are looking for warnings.  Otherwise, they may habituate themselves
to seeing the warning, and you will lose your chance to ever warn them.

Does this generalise to 'Python should never raise warnings unless
they are asked for'?  I don't know.  The v7 lint of 1983 or so was
one of the chattiest programs on the planet.  And most of the warnings
that our soldiers got were about bad code in somebody else's library
which they couldn't modify anyway.  So the pressure to become blind
to warnings -- all warnings -- was pretty high.  This isn't the case
with Python.  And the cognitive load to program at all, doing
string manipulation in C using ed as your programming language of
choice ... I know that at the time I did not think I was doing anything
particularly difficult, but I was 20 then.  I cannot imagine doing it
now.

What I object to is the blind acceptance of the notion that 'it
will do good for programmers to see deprecation warnings that they
were not expecting or looking for'.  All the evidence I know runs
against this one - first they won't see them because they weren't
looking for them ... their minds are on other things, and then
they won't see them because they _CANNOT_ any more, because they
have been overly exposed to such things.

It would be really nice to run a cognitive experiment to test how
well warning messages are seen.  We ran one at DCIEM to test this.
We had our soldiers' lint runs changed so that for each of them,
8 times in a day, they would get a lint warning that would
instruct them to say a certain word to a certain person (in the
room where the printer was) for a small reward ... a chocolate bar,
a piece of pie, and the important note on their service record
that they were an exceptionally observant person.  In a group of
35 soldiers, we generally got 4-5 who saw every message and 18-22
who saw none.  Of course, this was _after_ they had been habituated
to seeing the messages.  I don't know how it would work for fresh
students.

One thing we were able to prove -- which has been amply demonstrated
by others -- is that newbies who lack the experience to trust their
ability to 'overlook those things that do not matter' are those best
served by warning messages.  They pay attention better than the
experienced.  But I don't see any way to identify new python
users and give them more warnings than others showing up any time soon.

Laura