[stdlib-sig] Breaking out the stdlib

[Michael Foord]

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.

It would be a shame to stall either issue because of controversy around 
the other.

> 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).

> 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.

Michael
> 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
>   


-- 
http://www.ironpythoninaction.com/