[stdlib-sig] Breaking out the stdlib

[C. Titus Brown]

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.

<relurk>

cheers,
--titus
-- 
C. Titus Brown, ctb at msu.edu