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 _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
