On Tue, Nov 10, 2009 at 10:48 AM, Ronald Oussoren <[email protected]> wrote: > > On 10 Nov, 2009, at 16:31, geremy condra wrote: > >> On Tue, Nov 10, 2009 at 10:19 AM, Ned Deily <[email protected]> wrote: >>> In article >>> <[email protected]>, >>> geremy condra <[email protected]> >>> 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, >>> [email protected] >> >> 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 [email protected] http://mail.python.org/mailman/listinfo/stdlib-sig
