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@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