[stdlib-sig] standardizing the deprecation policy (and how noisy they are)

[Barry Warsaw]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/stdlib-sig/attachments/20091110/142eb42d/attachment.pgp>