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

Ronald Oussoren ronaldoussoren at mac.com
Tue Nov 10 16:38:55 CET 2009

On 10 Nov, 2009, at 16:28, Antoine Pitrou wrote:

>> If the package is a stand-alone application (c.f. Barry's bzr example), 
>> it's not reasonable to ask end users to modify its code; they may not 
>> even be able to easily (i.e. root privileges required).  More generally, 
>> it seems unfair and unwise to ask the 10 000 users of a package to take 
>> action when ultimately the 1 maintainer of the package is the one who 
>> needs to do so.
> That's why it is advised to report the problem to the maintainer (or
> perhaps the packager, in case e.g. of a linux distro), like you do for
> any other bug.
> 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).
> On the other had, having the application break when upgrading to Python
> N+1 would be critical.

A significant part of the code I write are command-line tools for system administrators. When they see the deprecation warnings they ignore them at best, and at worst get the impression that Python sucks because of these (to them) annoying messages.

As Brett and others noted DeprecationWarnings are useful for the developer of a module, not for their end-users. Unlike to compiled languages end-users get to see Python's Deprecation warnings.

> (*) All these are developer tools by the way, not end-user apps.

Why is that relevant? Bzr and hg are not only for Python developers, they can just as well be used for other code or even configuration files.    I know that I get annoyed by "random" messages from Java tools that I use, which doesn't help improve my opinion of that language.

> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/stdlib-sig/attachments/20091110/91c618cb/attachment-0001.bin>

More information about the stdlib-sig mailing list