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

[Leonardo Santagada]

On Nov 10, 2009, at 2:49 PM, geremy condra wrote:

> On Tue, Nov 10, 2009 at 11:00 AM, Guido van Rossum  
> <guido at python.org> wrote:
>> On Tue, Nov 10, 2009 at 7:31 AM, geremy condra <debatem1 at gmail.com>  
>> wrote:
>>> Let me rephrase- I'm not asking end users to silence them, I'm
>>> saying that if it annoys the end users so much, the devs should
>>> do it themselves.
>>
>> So either way the developers must be aware of the warnings.
>
> I don't understand how default suppressing all warnings implies
> that a developer "must" be aware of them.
>
>> In your proposal, every developer must add a special hack to
>> their code as distribute, which they must disable when they test.
>
> You only need the "special hack" (I'd point out that its in the
> standard library docs) if you're running deprecated code. Leave
> it off until a warning comes up, then decide what you're going
> to do about the warning, then suppress it. The important thing
> was that you were made aware of the problem and then made
> a conscious decision to do something about it, rather than
> being totally unaware of the problem until it became an error.
> That's no better than no warnings at all.

So you are saying that developers should re-release their software  
when a new python release happens just to put some code to disable  
warnings? It does take effort to make a software release, and every  
time you do one is a chance to screw things up (even python had  
releases issues). For me it is unacceptable.

> 3) As I've said before, if you don't think the warnings are
> important info, then ask pylint and pychecker to take them
> up and take them out of Python. That's the case where
> there isn't any burden on either the conscientious dev or
> the end user.


Good that you agree on taking the warnings out of python :)

--
Leonardo Santagada
santagada at gmail.com