Re: [stdlib-sig] standardizing the deprecation policy (and how noisy they are)
In a message of Mon, 09 Nov 2009 17:35:35 +1100, Ben Finney writes:
Laura Creighton <lac@openend.se> writes:
So constantly spitting out DeprecationWarnings as soon as something becomes deprecated is a most excellent way to train people to ignore DeprecationWarnings. [â¦]
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?
Ben Finney
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. Laura
from http://eight.pairlist.net/pipermail/geeklog-devel/2008-December/003950.html
FYI: When pulling from / pushing to the Mercurial repository, you may see warning messages like these: [snip] You can ignore them for now - things should work just fine nonetheless.
A Python upgrade on the webserver broke the repository viewer and after repairing this, you now get these messages. I guess we'll have to upgrade to Mercurial 1.1 eventually.
bye, Dirk
What would happen if a single untested mercurial feature just broke? I hope you realize this IS going to happen. Someone, somewhere is going to one day see his code just breaking without warning. If the warnings are annoying to you, lengthen the deprecation period so the day of magic breakage will be the day the annoying warning starts. People who are annoyed by warnings have no point in the argument except for shortening the cycle of change which is something I noticed python is against nowadays. == a visualization == today: working, working*, warning, breaking! Guido suggests: working, working*, working*, breaking! MIchael Foord suggests a win-win proposal: working, working*, working*, warning, breaking! * a special flag is needed for seeing silent warnings --yuv
On Mon, Nov 9, 2009 at 9:31 AM, Laura Creighton <lac@openend.se> wrote:
Because casual programmers are not motivated to go after Deprecation Warnings [ snip ] So lots of DeprecationWarnings will only train them to ignore DeprecationWarnings, or all Warnings.
Laura _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
This isn't just about casual programmers, everybody who uses python on a daily basis for just interpreter stuff, are they supposed to change their interpreter shortcut to have the warnings option just to stay up to date ? Not everyone that uses python is a package designer with unit tests and a buildbot that runs with all the most advanced configurations (that show hidden warnings). This warning hiding feature's just making python a bit more of a "dark art of the few who know it well". What ever happened to "unless explicitly silenced"? --yuv
2009/11/9 Laura Creighton <lac@openend.se>:
In a message of Mon, 09 Nov 2009 17:35:35 +1100, Ben Finney writes:
Laura Creighton <lac@openend.se> writes:
So constantly spitting out DeprecationWarnings as soon as something becomes deprecated is a most excellent way to train people to ignore DeprecationWarnings. […]
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?
Ben Finney
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.
Laura
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. Tim
_______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
participants (3)
-
Laura Creighton -
Tim Head -
Yuvgoog Greenle