Re: [stdlib-sig] standardizing the deprecation policy (and how noisy they are)
In a message of Mon, 09 Nov 2009 07:10:08 +0100, Antoine Pitrou writes:
There is also the argument that if people are told they have to explicitly turn on warnings to get them and the switch turns them all on then it might be the case that more people will see and deal with PendingDeprecationWarnings than they do now. The arguments that people will not switch them on is based on current practice. Guido's and Greg's argument is that habits will change such that it is not going to be an issue.
Well as I said this helps only if the package has 100% test coverage, such that the developer is sure to exercise all code paths when he/she runs the test suite with warnings explicitly enabled.
Besides, as Yuvgoog pointed out, this would not help the casual hobbyist programmer (or professional non-programmer, such as a scientist) who doesn't really have a clue that those warnings exist and are important to check for.
Regards
Antoine.
Experience has shown that when people get used to seeing 'a bunch of warnings that don't really matter' they either a) turn them off or b) ignore them, even when they are telling them valuable things that they should be paying attention to. So constantly spitting out DeprecationWarnings as soon as something becomes deprecated is a most excellent way to train people to ignore DeprecationWarnings. I appreciate the desire to help the casual programmer, but it is not clear to me that this will turn out to actually be helpful. Teaching people to run their code through some sort of code-checker every so often strikes me as more likely to be so. Laura
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? -- \ “The greatest tragedy in mankind's entire history may be the | `\ hijacking of morality by religion.” —Arthur C. Clarke, 1991 | _o__) | Ben Finney
Experience has shown that when people get used to seeing 'a bunch of warnings that don't really matter' they either a) turn them off or b) ignore them, even when they are telling them valuable things that they should be paying attention to. So constantly spitting out DeprecationWarnings as soon as something becomes deprecated is a most excellent way to train people to ignore DeprecationWarnings.
Well at least people get a chance to see them. If some people think the warnings are useless (even though the messages warn about removal of a construct), they won't run a code checker either. If Mercurial users and developers hadn't seen those warnings at all, perhaps Mercurial would have continued using deprecated constructs, and ended up broken when the N+1 Python version had been released. If even an established FLOSS project such as Mercurial is vulnerable to this kind of risk, then any in-house or one-man project will be even more vulnerable. Besides, do we have such a code checker that is able to find out deprecated constructs (not talking about 2to3 here) ?
[Laura]
Experience has shown that when people get used to seeing 'a bunch of warnings that don't really matter' they either a) turn them off or b) ignore them, even when they are telling them valuable things that they should be paying attention to. So constantly spitting out DeprecationWarnings as soon as something becomes deprecated is a most excellent way to train people to ignore DeprecationWarnings.
On Sun, Nov 8, 2009 at 10:39 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Well at least people get a chance to see them. If some people think the warnings are useless (even though the messages warn about removal of a construct), they won't run a code checker either.
You're misreading Laura. She's not saying that some people choose to ignore the warnings. She's pointing out that it is a scientifically known fact that people will *learn to ignore warnings* if they occur frequently enough, and that once this is learned the warnings have no effect. Look up Jef Raskin's diatribes against modal dialogs. (Or read the "cry wolf" fairy tale. :-)
If Mercurial users and developers hadn't seen those warnings at all, perhaps Mercurial would have continued using deprecated constructs, and ended up broken when the N+1 Python version had been released. If even an established FLOSS project such as Mercurial is vulnerable to this kind of risk, then any in-house or one-man project will be even more vulnerable.
If the Mercurial developers claimed that Mercurial supported Python 2.6 without extensive testing they would be rank amateurs. I don't believe they are.
Besides, do we have such a code checker that is able to find out deprecated constructs (not talking about 2to3 here) ?
At Google we use a hacked-up version of pylint which seems infinitely flexible in the checks you can specify. I assume that the public version of pylint is just as capable -- someone just needs to write a rule for it. -- --Guido van Rossum (python.org/~guido)
On Nov 9, 2009, at 1:02 PM, Guido van Rossum wrote:
At Google we use a hacked-up version of pylint which seems infinitely flexible in the checks you can specify. I assume that the public version of pylint is just as capable -- someone just needs to write a rule for it.
Is that "hacked-up" version publicly available, or could it be? Thanks, S
On Mon, Nov 9, 2009 at 10:05 AM, ssteinerX@gmail.com <ssteinerx@gmail.com> wrote:
On Nov 9, 2009, at 1:02 PM, Guido van Rossum wrote:
At Google we use a hacked-up version of pylint which seems infinitely flexible in the checks you can specify. I assume that the public version of pylint is just as capable -- someone just needs to write a rule for it.
Is that "hacked-up" version publicly available, or could it be?
I don't know and have no time to dive into this, but I suspect it isn't of general interest, since AFAIK what we added is mostly rules to enforce Google-specific coding standards. -- --Guido van Rossum (python.org/~guido)
On Nov 9, 2009, at 1:11 PM, Guido van Rossum wrote:
On Mon, Nov 9, 2009 at 10:05 AM, ssteinerX@gmail.com <ssteinerx@gmail.com> wrote:
On Nov 9, 2009, at 1:02 PM, Guido van Rossum wrote:
At Google we use a hacked-up version of pylint which seems infinitely flexible in the checks you can specify. I assume that the public version of pylint is just as capable -- someone just needs to write a rule for it.
Is that "hacked-up" version publicly available, or could it be?
I don't know and have no time to dive into this, but I suspect it isn't of general interest, since AFAIK what we added is mostly rules to enforce Google-specific coding standards.
Ok, thanks, S
I understand some people on this list ran code that kept giving them warnings until they were "warning-blind" so I'd like to know why they didn't run python with "-W ignore" and enjoyed a warning-less world of wonder? Either that or I'd rather these ultimate-and-bug-less-that-run-with-special-options programmers to add the ignore warnings stuff in their code, that way when their code magically breaks upon a language change, there's proof that the real problem was their ego. If you feel it's hard to ignore warnings, then make it easier, don't break the system because it's a good one that's saved me and many others from doing silly things we would have never noticed until it was too late. --yuv
On Nov 9, 2009, at 10:02 AM, Guido van Rossum wrote:
[Laura]
Experience has shown that when people get used to seeing 'a bunch of warnings that don't really matter' they either a) turn them off or b) ignore them, even when they are telling them valuable things that they should be paying attention to. So constantly spitting out DeprecationWarnings as soon as something becomes deprecated is a most excellent way to train people to ignore DeprecationWarnings.
On Sun, Nov 8, 2009 at 10:39 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Well at least people get a chance to see them. If some people think the warnings are useless (even though the messages warn about removal of a construct), they won't run a code checker either.
You're misreading Laura. She's not saying that some people choose to ignore the warnings. She's pointing out that it is a scientifically known fact that people will *learn to ignore warnings* if they occur frequently enough, and that once this is learned the warnings have no effect. Look up Jef Raskin's diatribes against modal dialogs. (Or read the "cry wolf" fairy tale. :-)
Case in point, Plone collected more and more deprecation warnings over the years. When Zope started down the DeprecationWarning road, there were just a few warnings, but people got used to them. After a few years went by, starting the application server used to emit a truly hideous amount of warnings. End-users saw these warnings and it was embarrassing. 3rd party developers using it as a framework saw these warnings and it just frightened them off. Despite being such a bad situation, the Plone core developers saw these warnings and did nothing to fix them, they just learned to ignore the situation when starting Plone - despite it being a major source of embarassment for them, everyone just got used to ignoring them (until finally Hanno took mercy and the led the charge to clean-up the morass). Andy McKay complained, "Do I really need to see all this? Can we put this into a unit test that will do something like test --show- deprecations? Deprecation warnings in products I develop are useful, but I fear, I like most or just ignoring these logs. If that's the case we are losing the battle." http://www.agmweb.ca/blog/andy/1849/
Le lundi 09 novembre 2009 à 15:43 -0800, Kevin Teague a écrit :
Despite being such a bad situation, the Plone core developers saw these warnings and did nothing to fix them, they just learned to ignore the situation when starting Plone - despite it being a major source of embarassment for them, everyone just got used to ignoring them (until finally Hanno took mercy and the led the charge to clean-up the morass).
So, the question is: would anyone have led the charge if there had been no visible warnings, and no morass to clean up? As an insider, what is your thought about it?
On Nov 9, 2009, at 3:52 PM, Antoine Pitrou wrote:
Le lundi 09 novembre 2009 à 15:43 -0800, Kevin Teague a écrit :
Despite being such a bad situation, the Plone core developers saw these warnings and did nothing to fix them, they just learned to ignore the situation when starting Plone - despite it being a major source of embarassment for them, everyone just got used to ignoring them (until finally Hanno took mercy and the led the charge to clean-up the morass).
So, the question is: would anyone have led the charge if there had been no visible warnings, and no morass to clean up? As an insider, what is your thought about it?
The morass would have been cleaned up anyways, since the excessively large amount of deprecations was acknowledged that Plone needed major refactoring towards a cleaner code-base. I'm not exactly sure how much the annoyance of the deprecations warnings played a role in accelerating this - probably Hanno or Wichert would be better people to ask. I only observed these warnings with annoyance since I only do Plone work as an integrator (e.g. used Plone-as-framework). Another thing that happened with all the deprecations in the Zope world was DeprecationWarnings that had a long shelf life, generally a couple of major releases, so around is three years or more. And at the end of that point whomever initiated the deprecation is no longer leading the charge for it, since they've moved on to other things. The project itself shifted direction, and despite the deprecation warnings, people would still use the old APIs (newbie developers) or people would not want to go in and maintain their 3-year old code that relyed on it and not want it to break needlessly. So there would be opposition to removing the deprecation at that point. For example, Zope 3.4 is the last proper Zope 3 release, but there are still packages with deprecation warnings such as, "This function has been deprecated and will go away in Zope 3.6." or "The ``localUtility`` directive has been deprecated and will be removed after 09/2007." M.-A. Lemburg made a good point, "Don't raise the bar for warning messages, raise the bar for deprecations themselves.". In Zope this was generally adopted for many of those deprecations. Warnings were spewed, people got annoyed, people lost interesting refactoring/ cleaning that particular code, and in the end after building up "warnings immunity" it was agreed to just leave the BBB shims in there ... they weren't hurting anything beyond adding a few kilobytes to the size of the tarballs. (although there has been quite a bit of movement just recently towards cleaning up the better packages from Zope 3 and releasing them in the form of the Zope Toolkit). As for me, I've become so blind to warnings that I couldn't tell you of the top of my head if Python deprecated md5 -> hashlib or vice- versa. Nor do I really care, I've never needed to interact with those modules directly, but I've seen them spewed on the console a lot. There are lots of cases where Python code is run on the command-line and you aren't directly invoking it with the interpreter where you can easily silence the warnings (although again, I've never bothered with silencing them, I, like many, just learned to ignore them ... they're annoying but not so annoying to want to have to rememeber to type extra syntax every time you run the interpreter). Some notable command- line Python apps where you can't easily put in a -W: $ hg $ buildout $ pip $ zopectl $ paster As for the code I write, I tend to favor packages outside the standard library these days since they can move forward with refactoring in a more timely manner, and I can make explicit those dependencies in the setup.py's install_requires field. If a package requires 'argparse', then it specifies that. If a package requires 'opster', then it specifies that. No need for deprecation warnings saying argparse -> opster or vice-versa. When the package is installed, it pulls in the packages that it says that it needs. Simple as that. But I don't think the DeprecationWarning discussion is entirely fruitless. I'd imagine that Distutils in particular is going to need to do some deprecations in order to make things "right" in packaging land.
On Nov 9, 2009, at 12:39 AM, Antoine Pitrou wrote:
If Mercurial users and developers hadn't seen those warnings at all, perhaps Mercurial would have continued using deprecated constructs, and ended up broken when the N+1 Python version had been released. If even an established FLOSS project such as Mercurial is vulnerable to this kind of risk, then any in-house or one-man project will be even more vulnerable.
There are two different use cases here. I'll s/Mercurial/Bazaar/ since I'm more familiar with the latter. We have bzr the command line script and bzrlib the library. When I use or develop bzr, I would be fine with seeing the DeprecationWarnings, and using those to pressure upstream to make bzr compatible with newer versions of Python. As a client of bzrlib from a different application, I'm much less happy about those DeprecationWarnings because there's probably much less I can do about it. Maybe I didn't even realize that bzrlib got pulled into my application as a dependency, well until it started screaming at me. ;) I may not be able to fix those problems, and even if I could pressure upstream to fix them, it may not help me much because I'm using an egg, or even more glacially a package from my distro. So in this case, those warnings /are/ just noise and not always easy to shut off. -Barry
participants (8)
-
Antoine Pitrou -
Barry Warsaw -
Ben Finney -
Guido van Rossum -
Kevin Teague -
Laura Creighton -
ssteinerX＠gmail.com -
Yuvgoog Greenle