[stdlib-sig] Breaking out the stdlib

[Jesse Noller]

On Mon, Sep 14, 2009 at 11:41 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le lundi 14 septembre 2009 à 11:13 -0400, Jesse Noller a écrit :
>> Note, since I drafted this, brett's posted some thought on evolution
>> as well: http://sayspy.blogspot.com/2009/09/evolving-standard-library.html
>
> I tried to comment on it but, after a lot of pain editing my thoughts
> (the text editor on that blog is completely broken in my browser), it
> seems the comment got lost when I clicked "post"...
>
>> 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)
>
> Note, however, that an interpreter without stdlib is useless. Even basic
> I/O (on Python 3) may not function properly. Conversely, the stdlib will
> depend on certain interpreter features, or even implementation details.
> So, while we can put them in separate VCSes, the development of
> python-core and python-stdlib will be still be quite tied.

Understood; there is a simple "basic set of widgets" we do *need* -
but it's terribly smaller than what we have now.

>> python-full (the works)
>
> What is this? core + stdlib?

Yes.

>> From a packaging standpoint -
>> it's a lot easier to spin a new stdlib package and get it into an OS
>> upstream then the entire interpreter.
>
> I'm not convinced. A new stdlib can lead to as many compatibility
> problems as a new interpreter does. And it seems that compatibility /
> dependency management is the #1 problem in packaging.

I'm not trying to solve that, Tarek is ;)

>> I would personally like to see every single stdlib library have an
>> "owner" - I know, that's a long shot, but I really feel it's needed.
>> Otherwise you potentially have people reviewing patches for code they
>> may not fully understand, or not understand the ramifications of.
>
> On the other hand, having an owner can be detrimental to maintenance.
> For example, nobody wants to touch ElementTree except Fredrik, and
> Fredrik isn't very active these days.
> We should also say to no to externally-maintained modules, because it
> completely ruins maintenance for us core developers.

Then Fredrik is no longer the maintainer - I'm looking at this through
rather harsh eyes, true, but my goal is progress and quality - not
being nice, so I'm sorry if I'm overly harsh.

And externally maintained modules are an oxymoron, no? :)

jesse