[stdlib-sig] Breaking out the stdlib

[Jesse Noller]

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.

2> Take a hard look at the standard library; identify modules with low
test coverage, poor documentation, and without owners. 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

3> Identify modules which are not best of breed; and identify
replacements for them. I am not suggesting bleeding edge modules. No
one is. I am suggesting that we take a hard look at the modules and
ask ourselves "is there something else out there stable, clean and
mature, with an active maintainer which could be part of this
library?" This may end up being multiple PEPs.

If best of breed is too subjective - then how about "a viable, widely
used, high quality alternative exists".

Why?

Having a large, batteries included standard library is frankly what
makes Python Python - however, having something with old, unmaintained
modules with little-to-no tests and in the face of libraries in the
wild which are in a much better state serves no one.

I would like owners for every single module in the stdlib; we need
people who are willing to be domain experts for modules to review
patches, write tests and help us. Modules without owners with a vested
interest means we have to either take patches at face value, or simply
ignore the patches because we can not risk the change because we don't
fully understand it.

Note that "age" has nothing to do with this - older modules aren't
"bad" modules. Old, low test count, overly complex, no maintainer,
poor docs, non thread-safe, bad naming scheme modules are bad modules.

Having a bunch of crusty, leaky batteries doesn't help anyone. Needing
to explain to someone why they should not use something in the
standard library because it's either broke, or doesn't work with
current technology sucks.

Jesse