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