[stdlib-sig] Breaking out the stdlib

[Michael Foord]

M.-A. Lemburg wrote:
> [snip...]
> Please note that adding functionality to such class "C" module
> is still allowed - provided it doesn't break anything. This has
> been done with optparse and getopt a few times already and
> is common practice with other such modules as well.
>
> In Laura's particular case, there does appear to be an easy
> solution which adds just that one feature:
>
> http://code.activestate.com/recipes/573441/
>
> Things do get problematic if you want to approach a problem
> from a whole new angle, e.g. say you want to have XML DOM
> parsing instead of SAX parsing.
>
> In such a case, adding a whole new module would be better.
> Even though you're still parsing XML in both cases, the new
> module would provide a new method to do so. Much like the
> urllib2 provides a new and different way to handle URL
> fetching compared to urllib.
>
> There's also a third case: If a module cannot be updated
> or extended to support a major new feature mandated by
> the Python language, such as Unicode support, then there
> is little choice other than to replace it with a new module.
>
> This has happened with the pcre module that used to drive
> the re module - there was no way to get Unicode into pcre.
> The change was not really noticeable to the users, though,
> since the new module implemented the same API (and extended
> it).
>
>   

Modules are also deprecated wholesale where their functionality is 
replaced by an alternative API.

    md5 -> hashlib
    mimewriter -> email

This is already a normal part of the evolution of the Python standard 
library.

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog