[stdlib-sig] Breaking out the stdlib

[Jesse Noller]

On Tue, Sep 15, 2009 at 9:23 AM, Michael Foord <michael at 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!