[stdlib-sig] standardizing the deprecation policy (and hownoisy they are)
debatem1 at gmail.com
Tue Nov 10 17:58:49 CET 2009
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>
>>>> Ok, so whats wrong with just saying
>>>> import warnings
>>>> 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.
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.
More information about the stdlib-sig