[stdlib-sig] Breaking out the stdlib

[Michael Foord]

C. Titus Brown wrote:
> On Mon, Sep 14, 2009 at 04:35:54PM +0100, Paul Moore 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.
> -> >
> -> > 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).
> -> 
> -> 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...)
>
> I'd like to -1 this whole discussion by saying that you guys are basing
> this whole thing on your mature, competent skills of Python programming
> and computer use.  Corporations and beginning programmers need something
> straightforward, simple, with "batteries included" in order to do
> something sane with Python in large multi-user environments.
>
> We can discuss *which* batteries should be included -- bsddb was taken
> out, sqlite3 looks like a long-term winner -- but IMVSO pruning the
> stdlib should not be seriously consider until we have an excellent,
> time-tested, battle-proven completely automatic package installation
> system.
>
> To me, this could be like the decision to simultaneously release python
> 3.x and python 2.x distributions, but much worse: even more confusion-
> engendering and detrimental to short- and medium-term adoption of
> Python.
>
>   
I think we're discussing the organisation of development repositories 
and *not* changing the default distributions - just making alternative 
distributions easier. (at least -1 if that's not the context in which 
we're discussing this and +1 if it is.)

Michael



> <relurk>
>
> cheers,
> --titus
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog