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

[geremy condra]

On Tue, Nov 10, 2009 at 10:38 AM, Ronald Oussoren
<ronaldoussoren at mac.com> wrote:
>
> 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.

<snip>

If you're so worried about the warnings, suppress them. You control the code.

Geremy Condra