[stdlib-sig] Breaking out the stdlib

[Doug Hellmann]

On Sep 14, 2009, at 11:13 AM, Jesse Noller wrote:

> Note, since I drafted this, brett's posted some thought on evolution
> as well: http://sayspy.blogspot.com/2009/09/evolving-standard-library.html
>
>
> So, here's a small pile of thoughts - the main driving force of which
> was the common sentiment that was shown in the language summit at last
> pycon. I'm mainly sending this out to evoke some discussion.
>
> Last pycon, many of us agreed that the stdlib needed to be "broken"
> out of the core within source control. AFAIK, this is still pending
> the mercurial migration. The goal of this would be to have one common
> stdlib shared amongst the implementations (Jython, Ironpython, etc).
> Modules which were cpython-only (such as multiprocessing) would be
> kept near-core, or marked as Cpython only.
>
> This means we would have an interpreter/builtins section for cpython,
> one for Jython, etc while they could all consume the central stdlib
> blob.
>
> In thinking about this even more over the past year(ish) - I've
> wondered if the stdlib, and python-core should actually be *really*
> separated. I'm a huge fan of batteries included, but I can see the
> draw to a breakdown like this:
>
> python-core (no stdlib, interpreter, core language)
> python-stdlib (no core)
> python-full (the works)

It would be interesting to know what stdlib modules are a minimum  
requirement to install other packages with a tool like easy_install or  
pip.  Those might need to stay in "core" so that installing core gives  
a minimally functional system.

Otherwise, I like the idea.

Doug