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

[Georg Brandl]

geremy condra schrieb:

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

I don't read the documentation.  I write it.

Of course I can filter out only deprecation warnings occurring in a sphinx.*
module.  But then the extension author who wants to see them has to change my
code so that he can see the warnings again.  That's not easier than running
"python -w", is it?

And that's the problem with the warnings being displayed by default: it gives
me extra work to figure out what to filter and to add that filter to all my
programs, and it gives the user of a program or library extra work to figure
out where the warnings are filtered, and to remove that code.

Even worse, if no warnings are emitted, but would be emitted by default, people
probably wouldn't even look for a warnings filter but assume the code is OK.
With warnings silenced but activated with a simple -w flag, they *know* they
are silent and they can use -w to show them.  Much simpler, much more
consistent.

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

There's never a "need" to make any change.  Why introduce "with"?  A simple
try-finally is all you need.  Etc.  We make these changes because we think
that they benefit our users, make life a bit easier and coding a bit more
fun.  Seeing deprecation warnings every time I run hg was no fun at all.

Georg