On Mon, Sep 14, 2009 at 1:28 PM, M.-A. Lemburg <m...@egenix.com> wrote: > Michael Foord wrote: >> M.-A. Lemburg wrote: >>> I don't really understand how breaking something as useful as >>> the stdlib into smaller pieces would help with anything. >>> >>> The main purpose of a library is that you have an *integrated* set >>> of modules that are known and tested to work together. >>> >>> The stdlib has gone a long way in trying to achieve that and it's >>> getting better at it with every release. >>> >>> >> The particular motivation is to make it easier for other implementations >> to reuse the standard library. It was something discussed (with the >> maintainers of some of these implementations) at the Python Language >> Summit. > > The stdlib already has a lot of support for different Python > implementation built right into the code. > > There will always be some things that don't work in certain > implementations, but if that's the problem, we could just > add an assert at the top of the module or raise an ImportError > to warn the user.
The proposal was to separate the stdlib into two logical components: 1) a shared, this-has-to-work-everywhere standard library that all Python implementations share on equal terms; 2) an implementation-specific standard library for things that are either implementation details or that require Jython/IronPython/PyPy-specific implementations. The test suite would be similarly exposed and shared between all implementations on equal terms: one set of this-has-to-work-everywhere tests, one set of implementation-specific tests layered on top of the shared test suite (think garbage collection vs refcounting, etc). Same idea for documentation. The idea is to a) put CPython on a more equal footing with the other implementations, and b) to remove the need to have Jython/IronPython/PyPy-specific cases in the CPython standard library. I believe there was a more formal explanation of the plan sent to this list and/or python-dev shortly after PyCon US 2009; I'll see if I can dig it up. Collin Winter _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
