<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 14, 2013 at 11:47 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 14 August 2013 11:08, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>


> We take adding a module to the stdlib very seriously for all of these<br>
> reasons and yet people seem to forget that the exact same reasons apply to<br>
> modules already in the stdlib, whether they would be added today or not (and<br>
> in this instance I would argue not). There is a balance to keeping the load<br>
> of work for core devs at a level that is tenable to the level of quality we<br>
> expect from ourselves which means making sure we don't let cruft build up in<br>
> the stdlib and overwhelm us.<br>
<br>
</div>I've already suggested a solution to that at the language summit [1]:<br>
we create a "Legacy Modules" section in the docs index and dump all<br>
the modules that are in the "These are only in the standard library<br>
because they were added before PyPI existed, aren't really actively<br>
maintained, but we can't remove them due to backwards compatibility<br>
concerns" category there.<br>
<br>
Clear indication of their status for authors, educators, future users<br>
and us, with no risk of breaking currently working code.<br></blockquote><div><br></div><div>I view a deprecation as the same thing. If we leave the module in until Python 4 then I can live with that, but simply moving documentation around is not enough to communicate to those who didn't read the release notes to know modules they rely on are now essentially orphaned.</div>

</div></div></div>