[stdlib-sig] Breaking out the stdlib

[Jesse Noller]

On Mon, Sep 14, 2009 at 12:09 PM, Michael Foord
<michael at voidspace.org.uk> wrote:
> 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
>

Michael is correct; Titus is incorrect.

Titus; I'm taking in the needs of those just starting with python - I
would not, WOULD NOT have started using python if it had not come with
batteries. That's why I left python-full in the email.

What I am proposing, however, is we:

1> Separate them in source
2> Offer "core, stdlib, full" downloads - so we keep the simple,
simple - and allow for the more complex/nuanced uses.
3> Be aggressive with the *quality* of the modules

Sure, having batteries is fantastic. Until you being to realize that
some modules are broken, not up to date with current technology, etc,
etc. We have to be aggressive with cleaning it up.

In short; leaving crap in there "just because" doesn't make it better
- it just makes it bigger.

I can't even begin to describe the pain I went through when - new to
python, I tried to deal with XML parsing. Or the joy I felt when I
sent email for the first time using smtplib.

Things within the stdlib must have a high quality bar, and should
really represent the "one way of doing something" - meaning best of
breed, high quality, idiomatic, etc.

jesse