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

[geremy condra]

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

http://docs.python.org/3.1/library/warnings.html#module-warnings

Its a pretty well thought out interface, actually. In the cases you
mention (obviously without looking at your code) I'd suggest that
you subclass warning and filter based on that.

Geremy Condra