[stdlib-sig] standardizing the deprecation policy (and how noisy they are)
solipsis at pitrou.net
Mon Nov 9 12:37:05 CET 2009
Le lundi 09 novembre 2009 à 09:17 +0100, Laura Creighton a écrit :
> The conclusion is that 'surprising' people with unexpected warnings
> is less useful than one would think -- people tend to overlook them,
> and thus not be surprised.
Whether or not it's "less useful than one would think" doesn't make it
useless. There are many things which fall under the former predicate and
not under the latter. For example documentation (many people don't read
it), unit tests (they give a false sense of security)... do you suggest
we drop them too?
> It's better when people get warnings
> which they have asked to see.
Well, I don't see a contention here: they already can. If they want to
get warnings, they just have to run the program. It's not like Python
writes out lots of warnings, which is why you normally don't /need/ to
choose a specific kind of warning to display.
(-3 is an exception because it /can/ output many more warnings than is
reasonable, but that's part of why it is opt-in rather than opt-out)
> But I would suspect that blasting out all the DeprecationWarnings
> for 3 whole releases before something goes away would err on the
> 'so frequent that it is ignored' side.
I don't think anybody suggested that.
> I was thinking of something more primative, such as running your
> code with all warnings on from time to time.
Which gives far less code coverage than enabling them by default.
More information about the stdlib-sig