[Python-Dev] Deprecated xmllib module

[Barry Warsaw]

On Sun, 2004-12-05 at 05:40, Raymond Hettinger wrote:

> * The number one current python complaint is the state of the standard
> library:  http://www.internetnews.com/dev-news/article.php/3441931 .
> Some of this may just be the fruits of AMK's highly publicized journal
> entry; however, I think the concerns about library quality will persist.

I don't know if I'd use one quote from this article to infer that
standard library issues are the #1 complaint.  But besides that, there's
no question IMO that the standard library should be the place where
future Python development efforts are focused (not exclusively, but
predominately).

> * The average quality of the library improves as we take out junk (the
> tzparse module for example) and put in high quality modules like
> logging, csv, decimal, etc.
> 
> * After working through the tutorial, another huge task for aspiring
> intermediate Python programmer is to learn about the standard library.
> That task is made much difficult by the presence of obsolete,
> incomplete, and/or supplanted modules.

You don't have to remove modules to make this happen.  Few developers
find modules by doing an 'ls' on Lib -- they look to the library
reference docs, books, and existing code.  So for example, the re-org I
did on the string module docs for 2.4 should help, because now you can't
look up a string function such as atoi() without seeing that it's
deprecated.   A developer writing new code hopefully wouldn't even waste
time learning about those functions, and instead hop right to the
preferred string methods.  Yet, there's no push in the community to
actually remove those deprecated functions from string.py.

> For example, the high quality, actively maintained email package
> supplants several older, incomplete, or non-actively maintained modules.
> The library would be cleaner, more presentable, and easier to use if the
> old ones were to fall by the wayside.

Yes, but there's still /a lot/ of work to do to update the existing
standard library to use the email package.  We debated this during 2.4
and decided we can't even add deprecation warnings to things like
rfc822.py until we do.

> * Ideally, the library will develop in a way that doesn't have a
> cluttered concept space.  This will help get it back to the point where
> you can hold it in your head all at once and still be able to think
> about the problem domain.  Keeping cruft impedes that goal.

Agreed, but I think it's mostly going to be an organic process over
time.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/python-dev/attachments/20041205/71ac1d23/attachment.pgp