[stdlib-sig] standardizing the deprecation policy (and how noisy they are)
betatim at gmail.com
Mon Nov 9 18:42:49 CET 2009
2009/11/9 Laura Creighton <lac at openend.se>:
> In a message of Mon, 09 Nov 2009 17:35:35 +1100, Ben Finney writes:
>>Laura Creighton <lac at openend.se> writes:
>>> So constantly spitting out DeprecationWarnings as soon as something
>>> becomes deprecated is a most excellent way to train people to ignore
>>> Teaching people to run their code through some sort of code-checker
>>> every so often strikes me as more likely to be [helpful].
>>Why is one of these helpful but the other one not so? Why can't the run
>>your code through a code-checker remain as easy as running the code
>>with the next version of Python?
> Because casual programmers are not motivated to go after Deprecation
> Warnings and modify their code to make such things go away. They're
> coding to a different standard, one where you don't go off and change
> things unless you absolutely have to. So lots of DeprecationWarnings
> will only train them to ignore DeprecationWarnings, or all Warnings.
When I run some code that isn't mine and it produces
DeprecationWarnings "everytime" I start it or do my usual stuff with
it, it annoys me. I then consider doing one of three things:
* update to most recent version of package and hope they have gone away,
* hack/update code myself to make them go away,
* search for a way to silence warnings because they are annoying.
Which of the three I do depends on which one is the easiest/least
effort. If the deprecation warning tells me which line to go to, and
basically what change to make (think the error sum(s for s in
list_of_strings) gives you) then I will do that. So maybe what we need
is good deprecation warnings that tell you how to fix the code to make
them go away.
> stdlib-sig mailing list
> stdlib-sig at python.org
More information about the stdlib-sig