[Python-Dev] Issues with Py3.1's new ipaddr

[Clay McClure]

On Mon, Jun 1, 2009 at 11:32 AM, Guido van Rossum <guido at python.org > wrote:

> I haven't read the bug, but given the extensive real-life use that
> ipaddr.py has seen at Google before inclusion into the stdlib, I think
> "deep conceptual flaws" must be an overstatement.

When the users of the library are also the authors of the library, it
is not surprising that the library enjoys "extensive real-life use."
The real test of a library is not how well it succeeds at one
installation, but how well it meets the needs of the larger user base.

Having read the code and the author's comments, it seems to me that
networking concepts not employed at Google have been neglected. While
some of these features are easily added to ipaddr, their omission
exposes a narrow view of the problem domain that has resulted in more
fundamental problems in the library, such as the conflation of
addresses and networks.

> I think we should just stick to "sorry, too late, try again for 3.2".
> We've done that with plenty of more important flaws that were
> discovered on the verge of a release, and I don't recall ever
> regretting it. We can always add more features to the module in 3.2.

My concerns are not so much about adding features as they are about
changing the API. Addressing the concerns that I and others have
raised requires making backwards-incompatible changes. Doing that now,
before ipaddr enjoys widespread deployment as part of the stdlib,
seems prudent. Removing ipaddr from 3.1 appears to me less painful
than fixing apps when ipaddr's API changes in 3.2.

If this were a core feature that many developers were anxiously
awaiting, I could understand the desire to release and iterate. But is
there really a pressing need for an IP library in the stdlib? Until a
satisfactory library is available for inclusion in the stdlib, the few
developers that do require such functionality can easily enough
download a library that meets their needs.

Clay