[stdlib-sig] standardizing the deprecation policy (and how noisy they are)
g.brandl at gmx.net
Wed Nov 11 10:01:29 CET 2009
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 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
More information about the stdlib-sig