[stdlib-sig] Breaking out the stdlib

[Michael Foord]

Orestis Markou wrote:
> [snip...]
>>
>> And that discussion then led back to the original discussion
>> about how to evolve the stdlib, since it included deprecation
>> of modules, which then resulted in my summary of the situation
>> w/r to the parsing libs.
>>
>> The two threads "should we try to add argparse?" and
>> "Breaking out the stdlib" both target the same basic
>> topic: How much change is needed and wanted in the stdlib ?
>>
>> Part of the answer involves looking at the maturity of new
>> code vs. that of the existing code and weighing added
>> features vs. breaking backwards compatibility.
>>
>> So to correct my summary: argparse has been stable for 2 years,
>> optparse for 7 years, getopt for >9 years (the last major
>> change was in 1998).
>>
>> Anyway, Frank is going to write a PEP covering splitting the
>> stdlib into chunks in order to simplify reuse in Jython,
>> IronPython, etc. so that's a good result.
>>
>> Just to avoid any misunderstandings: I don't have anything
>> against argparse or adding it to the stdlib.
>>
>> I'm only concerned about the effects of deprecating modules
>> that are in wide-spread use, in this case getopt and optparse,
>> without providing a drop-in API compatible replacement.
>
> A deprecated -> removed module can always exist in PyPI and manually 
> installed (or perhaps they can live in their own special place 
> stdlib-legacy). When a new version of Python comes out, people *do* 
> have to spend some time testing their apps, so if something has moved 
> from stdlib to stdlib-legacy, they can just install that in their site 
> packages and go on pretending nothing happened.
>
> For me, deprecating modules and adding new ones is more of a social 
> move - it shows that the Python community cares, and it moves Python 
> closer to the bleeding edge. I think it can be done without alienating 
> legacy users.
>

I don't think it is a goal for the standard library to be bleeding edge. 
We definitely allow other libraries to be bleeding edge and then steal 
them for the standard library once they have proven widely used, stable 
and best-of-breed.

Part of the problem is that there are a lot of 'legacy' modules in the 
standard library that don't meet these criteria by a long way. Removing 
those is one issue that Jesse is about to embark on addressing with a PEP.

I also disagree with those who think that having a stable standard 
library means having a genuinely dead standard library. If I have time 
I'll compose a response to that - but I don't think that is *possible* 
(unless we also stop improving Python the language) or desirable 
socially or technologically.

Michael

>>
>> Thanks,
>> -- 
>> Marc-Andre Lemburg
>> eGenix.com
>>
>
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig


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