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

geremy condra debatem1 at gmail.com
Tue Nov 10 17:49:34 CET 2009


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.

> In my proposal, developers must explicitly run with some flag
> (e.g. -w) when they test. The burden for the developer is about
> the same in the case of a conscientious developer, while in your
> proposal lazy developers place the burden on their users.
> I really don't see how your proposal is better.

1) I'd see the burden of typing python -w every time I tested,
or changing the #! on my test code and breaking it on 3.1
and back, as being much larger than the burden of typing
fifty characters once.

2) a lazy developer probably isn't paying attention to warnings
because he has no intention of fixing them before they blow
up. I'm pretty sure that's not a development habit that should
be well supported by Python.

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.

Geremy Condra


More information about the stdlib-sig mailing list