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
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
