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

[Georg Brandl]

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
>     warnings.filterwarnings("ignore")
> 
> or
> 
> 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 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.

> 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
tool.

Georg