[stdlib-sig] Breaking out the stdlib

[Orestis Markou]

On Sep 15, 2009, at 2:53 PM, Michael Foord wrote:
> There seem to be three positions:
>
> 1) Virtually no changes or improvements to the standard library at  
> all - nothing beyond maintaining compatibility with language  
> changes. (Laura)
> 2) New modules are acceptable but old modules should remain forever.  
> (Antoine)
> 3) New modules are acceptable and eventual removal of old modules is  
> desirable. (Brett, myself, Jesse and Frank)
>
> Marc-Andre seems to fall somewhere between 1 and 2 and Orestis wants  
> the bleeding edge. (Sorry for these caricatures but it seems  
> approximately right.)

To set the record straight:

I'm all for clearly marking 'old' modules in the documentation. When I  
started with Python, I remember not knowing which module to use from  
the selection in stdlib. I'm also all for pointing to alternatives on  
PyPI.

I'm also fine with removing truly obsolete modules (macpath, archaic  
audio and image support). I understand the need of keeping those  
around for people that truly need them, however I think they belong  
somewhere else, not in the stdlib.

As for adding new modules, I don't want the bleeding edge - let de  
facto standards emerge, then they can be blessed and included. I'm -1  
on creating a stdlib-bleeding. A pointer in the documentation to a  
module that is considered best of breed for a specific job should be  
adequate.

Sorry if I haven't expressed this clearly before.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/stdlib-sig/attachments/20090915/fe34835e/attachment.htm>