[stdlib-sig] Breaking out the stdlib
Jesse Noller
jnoller at gmail.com
Mon Sep 14 17:53:17 CEST 2009
On Mon, Sep 14, 2009 at 11:51 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> (sorry for the double post, Jesse)
>
> -------- Message transféré --------
>
> Le lundi 14 septembre 2009 à 11:42 -0400, Jesse Noller a écrit :
>>
>> 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.
>
> How is this easier with a separate stdlib? You have to do exactly the
> same job you have to do nowadays: prune useless modules, add the useful
> stuff you need.
>
Ah! You see, by it's very nature, breaking out the stdlib requires a
modification to the build tools which we lack now with the tight
coupling. We're going to need to build/evolve tools that would allow
multiple implementations to pull in modules, mark them as "jython
only" and so on.
Second, Bob and Alice would only need to hack the build process for
the stdlib *itself*. They can just download python-core, and *use*
that, their customizations are only to the python-stdlib.
Off the cuff (and no; I haven't thought about this terribly hard) you
could have a stdlib includes file ala Sphinx' index.rst file:
foo
bar
blatz
Which, when parsed, pulls in the stdlib modules to the build process.
If an item is omitted, it is included. Actually, a sphinx-*like*
structure makes a small amount of sense.
jesse
More information about the stdlib-sig
mailing list