[stdlib-sig] Breaking out the stdlib

[Barry Warsaw]

On Sep 15, 2009, at 1:54 PM, Antoine Pitrou wrote:

> Python's reputation will certainly get tarnished, however, if
> widely-used modules get deprecated and removed. We will already get  
> some
> damage with all of the py3k changes. No need to worsen our case, IMO.

I don't view this any differently than language evolution.  We have a  
__future__ mechanism and policy for how language features change in  
incompatible ways between versions.  Application developers may not  
like it, but it's published, they have forewarning, and a long period  
in which to migrate.  New versions of Python break applications every  
time despite this, and despite lengthy beta releases.  Yes, we get  
grief for that despite the policy, but tough.  This is an all- 
volunteer loosely-organized herd of cats who work on this stuff for  
fun, taking time away from family, hobbies and sleep.  Put up $10M/yr  
if you want to change that ('course, that's been tried <wink>).   
Still, we try to be responsible and responsive to our users, which is  
why we have a long deprecation period.

The stdlib is the same IMO.  It must evolve and that means cleaning  
out the cobwebs from time to time.  We can do it in a way that gives  
full disclosure and ample time to adjust, but I really don't have any  
sympathy for libraries and applications that /never/ want to update,  
even though I've been on that side many times.  If that's the case,  
then you will probably have a problem with upgrading Python /at all/  
stdlib stagnation or not.  Maintaining your own version of Python is a  
perfectly reasonable and viable option in that case.

OTOH, we don't have to be rash or uncaring about it.  A policy that  
provides an orderly, lengthy migration to better standard libraries  
seems responsible to me.  The first steps can be to add the new  
library and put a big red warning in the docs of the old code,  
followed in later years by deprecation warnings in the library and  
hiding of the documentation, followed by its complete removal many  
years later.  Heck, you probably won't even have to worry about it,  
it'll be your kids that have to actually remove it from Python :).

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/stdlib-sig/attachments/20090915/542b1b7d/attachment.pgp>