[stdlib-sig] standardizing the deprecation policy (and how noisy they are)
debatem1 at gmail.com
Wed Nov 11 16:59:42 CET 2009
On Wed, Nov 11, 2009 at 4:01 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> Yuvgoog Greenle schrieb:
>> On Mon, Nov 9, 2009 at 11:18 PM, Brett Cannon <brett at python.org> wrote:
>>> First, there is the app user perspective. If I use an application I do
>>> not need to see any warnings, ever.
>> So it comes down to either:
>> A. As things are - every ballsy app developer has to have this piece
>> of code laying around:
>> import warnings
>> B. we render warnings useless in our every day python lives except for
>> package buildbots that remember to run with -w (or whatever).
> On the contrary, I think that DeprecationWarnings will become much more
> useful when silenced by default, because people will use them *more*.
> >From experience, when thinking about emitting DeprecationWarnings in Sphinx,
> which is a command-line tool, I often don't bother, because *it still works
> anyway* and I don't want Sphinx users to see a screenful of warnings when
> just building their docs.
If you don't feel like your users need that information, don't give it to them.
Same thing goes for both sphinx and python in general.
> If DeprecationWarnings were silenced by default, I (and probably others too)
> would put them into the code more liberally, because I know that *when* they
> are displayed, they are displayed to someone who actually *wants* to fix the
> code that causes them.
> Of course I could use the "filterwarnings" incantation given above, but that
> defeats the purpose of the -W command line option, and *globally* silences
> warnings I don't even want to control.
Please read the documentation, you can filter what and how you
>> I would like a demographic on this, but I'm sure that either way
>> muting warnings will be a devastating blow to the spread of
>> information about what's new/old in python.
> Please stop trying to seed FUD.
> Most Python developers are flexible enough to get to know and use a new and
> useful tool when they are made aware of it, and using -w is a very simple
But also an unnecessary one. Everything you've described can
be done simply and without changing python's behavior. There's
just no need to make the change.
More information about the stdlib-sig