[stdlib-sig] Breaking out the stdlib

[Michael Foord]

R. David Murray wrote:
> On Tue, 15 Sep 2009 at 12:53, Michael Foord wrote:
>> There seem to be three positions:
>>
>> 1) Virtually no changes or improvements to the standard library at 
>> all - nothing beyond maintaining compatibility with language changes. 
>> (Laura)
>
> I think you misrepresent Laura's opinion.  She wants modules that
> are mature (stable) to remain in the library, but I did not hear her
> object to the addition of improvements.  (She said perhaps she should
> have objected to optparse, but that was a hypothetical conditioned on
> getopt being removed...if getopt remains (as she expected it would)
> she had/has no objection to optparse (or, presumably, argparse)).
>
It's a caricature - but hard to express in a single line. ;-)

Her explicit preference however is for a standard library that is 
"dead-as-a doornail whenever possible" and that I think is something 
that is actively against what many of the core developers are working for.

>> 2) New modules are acceptable but old modules should remain forever. 
>> (Antoine)
>> 3) New modules are acceptable and eventual removal of old modules is 
>> desirable. (Brett, myself, Jesse and Frank)
>
> Laura's objection was to this label of "old modules", as if all modules
> beyond a certain age were automatically bad and should be removed.

That's a complete mis-characterisation. No one has said modules should 
be removed just because they are old. Modules that are unable to evolve 
to meet requirements because of API design are a problem though. Merely 
because a library meets *some* use cases doesn't make it *good*.

There is also the related issue of what to do about duplicate 
functionality - particularly in the case of argparse and optparse where 
argparse will completely 'replace' the functionality of optparse and 
no-one advocating for keeping it is also willing to maintain it.

> There is an important distinction to be made between "old, broken,
> and not maintained", and "old, mature, and functional".
>
>> Marc-Andre seems to fall somewhere between 1 and 2 and Orestis wants 
>> the bleeding edge. (Sorry for these caricatures but it seems 
>> approximately right.)
>>
>> I'd still like to write a longer piece on why I think 1) isn't 
>> possible and 3) is preferable to 2)  - but the basic points have all 
>> been covered in this thread anyway.
>
> Is anyone actually advocating (1)?  I doubt it.
>
> I think Laura's post was excellent and is worth a careful (re)reading to
> understand her points.
I think I understand her points and her motivation (and have sympathy 
for them), I just don't think they are really feasible (at face value) 
for a developing language. I think if you have a hard requirement for 
absolute stability then due to language changes alone you will have to 
stick to a specific version of Python.

Michael


>
> --David


-- 
http://www.ironpythoninaction.com/