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

Ned Deily nad at acm.org
Tue Nov 10 17:45:22 CET 2009

In article <1257866927.3579.20.camel at localhost>,
 Antoine Pitrou <solipsis at pitrou.net> 
> It should be stressed again that it is not a very common problem (how
> many Python apps do you routinely launch from the command-line, apart
> from hg, bzr, buildout & friends? (*)), and it's not a critical one
> either (you can perfectly live with it, like you can live with the
> occasional warning about a self-signed HTTPS certificate).

Not to belabor the issue, but I don't think that's a good analogy.  In 
the case of a self-signed certificate, I as an end-user do have a 
decision to make: whether to trust the certificate or not as it may have 
dire consequences in real life.  And I am the only one who can make that 
policy decision for me.  (Plus, the mail application and web browser I 
use anticipate this use case and provide user interfaces for me to 
easily evaluate the certificate and to capture my policy decision 
preference so I'm not pestered when the situation arises again.)

> On the other had, having the application break when upgrading to Python
> N+1 would be critical.
> (*) All these are developer tools by the way, not end-user apps.

Roles are relative: I would consider a Mozilla developer to be an 
end-user of hg.

 Ned Deily,
 nad at acm.org

More information about the stdlib-sig mailing list