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

[geremy condra]

On Wed, Nov 11, 2009 at 5:51 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> 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.

I'm well aware of your contributions to Python- I simply assumed that since
you were insinuating something wasn't possible when the docs made a
special point of mentioning that it was, you weren't aware that the
capability existed. No offense was intended.

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

I'd just extend sphinx's -w flag so that if it isn't given a filename it would
write to stdout. It also seems likely to me that that change would land
on your users machines much sooner than any change to python would,
although you would obviously know more about that than I would.

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

IMHO, thats the idea behind Python emitting warnings at all- that one of
the unspoken contracts between the program and Python has been broken
in a way that, while not immediately disastrous, will nevertheless
eventually end in tears. It is then the developer's responsibility to make
sure that the problem has been appropriately resolved, and to write
the appropriate (explicit, hopefully narrowly targeted) code to suppress
the warning in the event that it *is* superfluous.

I'd also like to point out that if you get the same passel of superfluous
warnings every time that you run under -w that you do normally, the
arguments raised earlier about error ennui become doubly relevant,
since now you now have the option of making them 'go play over
there' rather than cluttering up your screen.

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

This is the most convincing thing I've heard on this discussion so far.
Its a little bit of a consolation prize (sure, we broke your expectations
in a way that left you unaware that your code would blow up until it did,
but at least we did it consistently!) but assuming that every other option
were taken off the table I could understand this being considered a
virtue.

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

You're right, of course- 'need' is an impossibly high standard to meet
in a project as mature as python. The point I was trying to make was
that this proposal alters two of the (IMO) most important contracts
between developers and python (invocation and error notification),
that the bar for such a change should be set pretty high, and that I
don't think that things that can be easily accomplished inside of
the standard library should be seen as meeting that standard. Again,
YMMV.

Geremy Condra