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

[Kevin Teague]

On Nov 9, 2009, at 3:52 PM, Antoine Pitrou wrote:

> Le lundi 09 novembre 2009 à 15:43 -0800, Kevin Teague a écrit :
>> Despite being such a bad
>> situation, the Plone core developers saw these warnings and did
>> nothing to fix them, they just learned to ignore the situation when
>> starting Plone - despite it being a major source of embarassment for
>> them, everyone just got used to ignoring them (until finally Hanno
>> took mercy and the led the charge to clean-up the morass).
>
> So, the question is: would anyone have led the charge if there had  
> been
> no visible warnings, and no morass to clean up? As an insider, what is
> your thought about it?
>

The morass would have been cleaned up anyways, since the excessively  
large amount of deprecations was acknowledged that Plone needed major  
refactoring towards a cleaner code-base. I'm not exactly sure how much  
the annoyance of the deprecations warnings played a role in  
accelerating this - probably Hanno or Wichert would be better people  
to ask. I only observed these warnings with annoyance since I only do  
Plone work as an integrator (e.g. used Plone-as-framework).

Another thing that happened with all the deprecations in the Zope  
world was DeprecationWarnings that had a long shelf life, generally a  
couple of major releases, so around is three years or more. And at the  
end of that point whomever initiated the deprecation is no longer  
leading the charge for it, since they've moved on to other things. The  
project itself shifted direction, and despite the deprecation  
warnings, people would still use the old APIs (newbie developers) or  
people would not want to go in and maintain their 3-year old code that  
relyed on it and not want it to break needlessly. So there would be  
opposition to removing the deprecation at that point. For example,  
Zope 3.4 is the last proper Zope 3 release, but there are still  
packages with deprecation warnings such as, "This function has been  
deprecated and will go away in Zope 3.6." or "The ``localUtility``  
directive has been deprecated and will be removed after 09/2007."

M.-A. Lemburg made a good point, "Don't raise the bar for warning  
messages, raise the bar for deprecations themselves.". In Zope this  
was generally adopted for many of those deprecations. Warnings were  
spewed, people got annoyed, people lost interesting refactoring/ 
cleaning that particular code, and in the end after building up  
"warnings immunity" it was agreed to just leave the BBB shims in  
there ... they weren't hurting anything beyond adding a few kilobytes  
to the size of the tarballs. (although there has been quite a bit of  
movement just recently towards cleaning up the better packages from  
Zope 3 and releasing them in the form of the Zope Toolkit).

As for me, I've become so blind to warnings that I couldn't tell you  
of the top of my head if Python deprecated md5 -> hashlib or vice- 
versa. Nor do I really care, I've never needed to interact with those  
modules directly, but I've seen them spewed on the console a lot.  
There are lots of cases where Python code is run on the command-line  
and you aren't directly invoking it with the interpreter where you can  
easily silence the warnings (although again, I've never bothered with  
silencing them, I, like many, just learned to ignore them ... they're  
annoying but not so annoying to want to have to rememeber to type  
extra syntax every time you run the interpreter). Some notable command- 
line Python apps where you can't easily put in a -W:

  $ hg
  $ buildout
  $ pip
  $ zopectl
  $ paster

As for the code I write, I tend to favor packages outside the standard  
library these days since they can move forward with refactoring in a  
more timely manner, and I can make explicit those dependencies in the  
setup.py's install_requires field. If a package requires 'argparse',  
then it specifies that. If a package requires 'opster', then it  
specifies that. No need for deprecation warnings saying argparse ->  
opster or vice-versa. When the package is installed, it pulls in the  
packages that it says that it needs. Simple as that.

But I don't think the DeprecationWarning discussion is entirely  
fruitless. I'd imagine that Distutils in particular is going to need  
to do some deprecations in order to make things "right" in packaging  
land.