[stdlib-sig] Breaking out the stdlib

[Michael Foord]

M.-A. Lemburg wrote:
> Michael Foord wrote:
>   
>> 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.
>>     
>
> And that's perfectly ok.
>
> If the change is a single import statement, then I don't have a
> problem with that.
>   

For md5 the API basically moved (although md5.new became hashlib.md5).

For MimeWriter there were (what looks like from a relatively casual 
look) fairly big API changes as well - even if they were only name 
changes (which is substantially similar to the requirements for moving 
from optparse to argparse).

Michael

> I also don't have a problem with having a module called
> optparse, which, under the hood, uses argparse to provide
> the optparse API.
>
> I do have a problem with having to revisit the design of
> all scripts using a deprecated module in order to adapt
> it to some new, apparently deemed better, stdlib module,
> without any benefit, just in order to get the
> implementation or script working again.
>
> That's wasted time, really. And given that some modules are
> in wide-spread use that scales up wasting the time of
> thousands of other programmers out there.
>
>   


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