[stdlib-sig] Breaking out the stdlib

[Orestis Markou]

> BTW: This is fact is not off-topic at all - we are discussing
> evolving the stdlib and Jesse brought up the idea of breaking up the
> stdlib as answer to the discussions we had about getopt/optparse/
> argparse.
>
> This thread then shifted into a different direction:
> that of breaking up the stdlib to make life easier for other
> Python implementations than CPython.

This was the driving force - the discussions about deprecating and  
evolving stdlib came later. But yes, we are talking about a lot of  
orthogonal issues
.
>
> 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.

>
> Thanks,
> -- 
> Marc-Andre Lemburg
> eGenix.com
>