[stdlib-sig] standardizing the deprecation policy (and how noisy they are)
barry at python.org
Tue Nov 10 15:49:49 CET 2009
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,
> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 194 bytes
Desc: This is a digitally signed message part
More information about the stdlib-sig