On Tue, Sep 15, 2009 at 9:23 AM, Michael Foord <mich...@voidspace.org.uk> wrote: > Jesse Noller wrote: >> >> Since I've obviously had a failure to communicate, let me try to >> explain, once again, what my goals are, but first - here's the >> assumptions: >> >> a> The standard library is currently too large to maintain. >> b> The standard library contains things which are *not* best of breed. >> c> The standard library contains numerous modules which do not have >> adequate tests; docs or maintainers. >> d> The standard library is a monolith >> >> So, based on these assumptions, my proposal(s) were to: >> >> 1> Break the standard library into it's own section within the >> codebase; this solves D, and allows it to be used by the other >> implementations more easily. It also (hopefully) allows for a >> modularized build process by which individuals can be more selective >> with what is included. A PEP is being drafted for this. >> >> > > This all sounds very good Jesse - but can you make sure that your proposal > for splitting out the standard library for distribution is kept separate > (preferably a separate PEP). It seems orthogonal and something that will > attract a lot of debate on its own.
Yes, note I omitted the "separate for distribution" thing, as I'll write that up post-other-peps > It would be a shame to stall either issue because of controversy around the > other. > Agreed. >> 2> Take a hard look at the standard library; identify modules with low >> test coverage, poor documentation, and without owners. > > I would add to this "or of marginal utility". I think there are several > modules that have very few users and would never be included in the standard > library today (the calendar module springs to mind). Agreed. >> Add these to a >> "deprecation and removal" PEP for eventual removal. While this *will* >> break legacy scripts and applications, the likelihood of this >> happening in Python 2.x is infinitely small. This will more than >> likely occur in py3k, which *already* breaks those scripts. This makes >> me sad, as I'm handcuffed to python 2.x for some time, but I'm willing >> to cry myself to sleep about that in private. This, in theory, helps >> mitigate A and C >> > > It would be wise to emphasise *eventual* removal. I think a long deprecation > process leading to removal around Python 3.4 or 3.5 will give people > sufficient notice and hopefully mitigate *some* of the problems people have > with module removal. I assumed that was implicit ;) I too must obey the deprecation guidelines! _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
