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

[Ronald Oussoren]

On 10 Nov, 2009, at 16:31, geremy condra wrote:

> On Tue, Nov 10, 2009 at 10:19 AM, Ned Deily <nad at acm.org> wrote:
>> In article
>> <f3cc57c60911100650q551ca79em59d7c47ff61aa5a6 at mail.gmail.com>,
>>  geremy condra <debatem1 at gmail.com>
>>  wrote:
>>> Ok, so whats wrong with just saying
>>> 
>>> import warnings
>>> warnings.simplefilter("ignore")
>>> 
>>> and walking away?
>> 
>> 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.
>> 
>> --
>>  Ned Deily,
>>  nad at acm.org
> 
> Let me rephrase- I'm not asking end users to silence them, I'm
> saying that if it annoys the end users so much, the devs should
> do it themselves.

How do I do that for the libraries I distribute? Users of my libraries should not get DeprecationWarnings about my code, but I should be able to generate DeprecationWarnings of my own when I deprecate some of my APIs. Oh, and it should still be possible for me to check for DeprecationWarnings in my code.

Ronald

> 
> Geremy Condra
> _______________________________________________
> 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/625ab768/attachment.bin>