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