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

[geremy condra]

On Tue, Nov 10, 2009 at 4:02 PM, Leonardo Santagada <santagada at gmail.com> wrote:
>
> 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.

If its an absolute no-no that warnings be raised then blanket
suppress them. The snippet of code from the warnings module
should do the job.

>> 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 :)

I think this whole discussion is pointless bikeshedding. My
point here is that changing the way python is invoked doesn't
strike me as really solving the problem. If you believe that the
warnings are the problem, then lobby to have them taken out.
If you think the timeline for them is the problem, then change
that. If you just want to stop your users from seeing those
warnings, but think they're appropriate, then the tools to do
that already exist, and I would much prefer that you used
them.


Geremy Condra