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

[M.-A. Lemburg]

Antoine Pitrou wrote:
> Le lundi 09 novembre 2009 à 13:51 -0800, Guido van Rossum a écrit :
>> On Mon, Nov 9, 2009 at 1:47 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>> (have you ever launched a Gnome or KDE app from the command-line? they
>>> can spout *tons* of warnings)
>>
>> Yes, this is a perfect example of what I *don't* want to happen.
> 
> But it doesn't. Most Python applications display at worse one or two
> deprecation warnings, which is perfectly bearable.
> (the exception is -3, and that's why it's good to have it opt-in rather
> than opt-out)

I'm with Antoine here: I haven't seen a single warning from Python
in years... and I do use lots of 3rd party code in projects.
To me, this discussion appears a bit artifical.

Instead of worrying about too much noise on stderr we should reflect
more on whether certain deprecations are useful or not in the first
place, e.g. take the md5 module deprecation:

It would have been very easy to provide proxy implemenations for the
md5 and sha modules, redirecting to the hashlib module, instead of
going through the whole deprecation process, forcing developers to
clutter up their code with conditional imports and confusing newcomers
reading about the md5 module in their Python books.

After all, there's a reason why we still have the string module in
Python 2.7 without generating any warning whatsoever and properly
redirecting to the string methods.

IMHO, deprecations are only useful for things that are bound to
cause a change which doesn't allow for an option for providing
backwards compatible ways of letting older code continue to work
with more recent Python releases (even if it gets slower as result
of this indirection), e.g. Python syntax changes (such as changes
to the except clause) or changes to language semantics (such as
integer division).

In summary: Don't raise the bar for warning messages, raise
the bar for deprecations themsselves.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 09 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/