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. _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
