<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 15, 2009, at 2:53 PM, Michael Foord wrote:</div><blockquote type="cite"><div>There seem to be three positions:<br><br>1) Virtually no changes or improvements to the standard library at all - nothing beyond maintaining compatibility with language changes. (Laura)<br>2) New modules are acceptable but old modules should remain forever. (Antoine)<br>3) New modules are acceptable and eventual removal of old modules is desirable. (Brett, myself, Jesse and Frank)<br><br>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.)<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><br></div><div>To set the record straight:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.&nbsp;</div><div><br></div><div>Sorry if I haven't expressed this clearly before.</div></body></html>