[stdlib-sig] Breaking out the stdlib
Jesse Noller
jnoller at gmail.com
Mon Sep 14 17:42:57 CEST 2009
On Mon, Sep 14, 2009 at 11:35 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> 2009/9/14 Doug Hellmann <doug.hellmann at gmail.com>:
>>> 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.
Brett mentions that in his post; a minimal bootstrap. I didn't think
terribly hard about that aspect.
>> Otherwise, I like the idea.
>
> Please remember that some establishments have restrictions that mean
> that tools like easy_install or pip cannot be used. In locked-down
> corporate environments, python-full is potentially all that will be
> available (and maybe very specific "blessed" environment-specific 3rd
> party modules).
Yup. But 90% of the time, you're getting python-full from your OS
vendor, and if not, you just click on the full url :)
> But if the stdlib can be split out in such a way that it doesn't
> adversely impact those environments, then maybe the extra flexibility
> to evolve it would be helpful. (I'd like to know how that aligns with
> the stated goal of stdlib stability, though - seems to me like it's
> one or the other...)
>
> Paul.
>
Note; I too still need a python-full implementation. My argument is to
split them within source, and be able to use a single "source" for all
the implementations.
Let me give a concrete example. Let's say Bob and Alice are working on
a device which is severely space constrained. Bob and Alice love
Python but they only use a tiny subset of the stdlib. Right now
getting *just* the interpreter is painful at best.
Bob and alice have a second issue though - they still want good,
useful things like sockets, threading, and other low-level and
standard libraries, but simply don't need mimetools, an http server,
14 xml processing libraries and a package which goes "ping!". They'd
like to "roll their own" using some bits from python-stdlib, and maybe
some third party bits here and there.
jesse
More information about the stdlib-sig
mailing list