[stdlib-sig] Breaking out the stdlib

[Michael Foord]

Antoine Pitrou wrote:
> Le mardi 15 septembre 2009 à 11:57 +0300, Orestis Markou a écrit :
>   
>> When a new version of Python comes out, people *do* have to  
>> spend some time testing their apps, so if something has moved from  
>> stdlib to stdlib-legacy, they can just install that in their site  
>> packages and go on pretending nothing happened.
>>     
>
> Who is "people" in that sentence?
> It can be developers. But some applications or scripts have been
> developed years ago, by someone who isn't there to maintain them
> anymore.
> It can be users. But it is unreasonable (and quite rude) to expect users
> to fix compatibility problems by themselves.
> (do you think the average user knows what a "site packages" is?)
>
>   
To be fair, anyone relying on legacy Python scripts / applications that 
they have no desire or ability to maintain themselves will *soon* have 
to stick to the last version of Python 2.X anyway.

Within the foreseeable future vendors will have switched to Python 3 by 
default and Python 2 will finally be genuinely stable.

> There is the ideal world where every Python program (script,
> application, library, etc.) has a dedicated and active maintainer and
> regular releases to keep up-to-date with the state of the Python
> ecosystem. It is also the visible part of the iceberg (PyPI, Linux
> distros etc.), which is why some people assume it accurately describes
> reality.
>
> There is the real world where many programs are one-off solutions to
> specific problems, coded years ago, not maintained anymore because the
> coder has left for another place, and the users don't know Python.
>
>
>   
And eventually those programs stop working with the latest and greatest 
version of Python. That's the reality of bit-rot.

I read an article (on Planet Python I think) about code-examples from a 
C/C++ book that no longer compile with modern compilers (neither VS nor 
gcc). Languages change and Python has been better than others in this 
regard. The 2 to 3 transition will be very harsh from this point of view 
however.

Up until now we have been reluctant to remove modules, although several 
deprecated ones were removed in Python 3. My homebrew blogging system, 
which I haven't touched the code of in several years, now has several 
deprecation warnings from the standard library when I run it - because 
it uses the md5 and mimewriter modules that are now deprecated.

The question of removal is an interesting one. Dragging around legacy 
code that still needs to be maintained is a burden. We'll see what 
smattering of consensus we can reach when there is a PEP.

Michael


> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig
>   


-- 
http://www.ironpythoninaction.com/