On Tue, Nov 10, 2009 at 10:48 AM, Ronald Oussoren
<ronaldousso...@mac.com> wrote:
>
> On 10 Nov, 2009, at 16:31, geremy condra wrote:
>
>> On Tue, Nov 10, 2009 at 10:19 AM, Ned Deily <n...@acm.org> wrote:
>>> In article
>>> <f3cc57c60911100650q551ca79em59d7c47ff61aa...@mail.gmail.com>,
>>> geremy condra <debat...@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,
>>> ...@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
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
