On Mon, Jun 1, 2009 at 6:54 PM, Jake McGuire <mcgu...@google.com> wrote:
> On Mon, Jun 1, 2009 at 12:16 PM, "Martin v. Löwis" <mar...@v.loewis.de>wrote: > >> As for Clay McLure's issue: I feel it's primarily a matter of taste. >> I see nothing morally wrong in using the same class for hosts and >> networks, i.e. representing a host as a network of size 1. I can >> understand why people dislike that, but I don't see why it would stop >> people from doing with the library what they want to do. >> > > To the extent that Clay is having issues, it's because ipaddr.py is poorly > documented, has potentially confusing comments, and he became confused. > Lesser issues are that ipaddr.py doesn't work the way he wants and that ip > addressing is inherently subtle. > Sorry for the spam, I wrote my last message before reading the entire discussion surrounding the two libraries and trying to imagine using both ipaddr and netaddr. Clay is basically correct. The ipaddr.py API is missing important features, and it would probably be a mistake to add it to the python standard library if that means we'd have to maintain compatibility for the indefinite future. Like all largeish python projects, we wrote a library to do IP address manipulation. In our case, it's a whopping 64 lines long. While I wasn't aware of ipaddr.py or netaddr at the time, the API we created is much closer to netaddr's. Migrating our code to ipaddr would require significant work and is unlikely to happen. In fact, if I was starting a new project from scratch with similar requirements, I'd probably write my own library instead of using ipaddr. -jake
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
