[stdlib-sig] standardizing the deprecation policy (and how noisy they are)
kevin at bud.ca
Mon Nov 9 07:44:45 CET 2009
On Nov 8, 2009, at 9:25 PM, nathan binkert wrote:
>>> (Another argument to think about: if you download and install some
>>> party code, deprecation warnings about that code are *only noise*
>>> since they are not yours to fix. Warnings in a dynamic language work
>>> very different than warnings in a compiled language.)
>> That's very true. Until Mercurial caught up to Python 2.6 the sha/md5
>> warnings were very annoying. I actually modified my copy to turn them
>> off myself.
+1 for making warnings silent unless asked for.
There is a time when I'm in "migration and maintenance mode" when I
want to see these warnings and fix them. When I'm not in this mode,
deprecation warnings are like some annoying co-worker who stops by
every 15 minutes with a super trivial questions to which you respond,
"Go away, do a Google search for the answer!" The nagging of seeing
deprecations all the time doesn't make me want to fix the deprecations
even more, but tends to have the reverse effect. Maybe a flaw in
myself, but quite a common one in humans I think :P
> I too find this sort of thing very annoying. Perhaps we should teach
> people to install their programs with
> #!/usr/bin/python -W ignore
> This way pending deprecations are on by default, but people that
> install programs will not have them.
Hey, I'd never thought of this before. I'd still rather reverse it,
and teach people how to install with warnings enabled.
For those installing scripts with Buildout, you can use
"initialization = sys.warnoptions = ['ignore']" to silence warnings.
Here's a Buildout with the necessary configuration for "silent"
Mercurial install (not that a silent install is necessary ATM, but it
would "protect" you if a future release re-introduced new deprecation
parts = mercurial
recipe = zc.recipe.egg
eggs = mercurial
entry-points = hg=mercurial.dispatch:run
sys.warnoptions = ['ignore']
Speaking of, I need to submit a patch to mercurial so that the command-
line entry point is specified. But like seeing deprecation warnings in
third-party code, it's always a big chasm to approach some project
which you have no involvement in (and need to determine if fixes are
done on a mailing list, personal e-mail, issue tracker, etc.) for such
a trivial fixes as entry points and deprecation warnings ...
More information about the stdlib-sig