David Moss <drk...@gmail.com> added the comment: ipaddr appears to be on a fast track for "batteries included" status without much consultation in the wider Python community. As BDFL it's ultimately Guido's call, but it would be disappointing to see one solution being chosen wholesale without much additional discussion.
There is no point in wrangling over the individual features of one library at revision x versus another at revision y. Software is a moving target. Omissions and bugs are easily dispatched. Ultimately we all want the same thing, better software that makes our lives easier. As for netaddr it is intended to cover more ground that all the other solutions out there. Here is a handy list of them :- http://code.google.com/p/netaddr/wiki/YetAnotherPythonIPModule This may preclude its suitability for the standard library in any event being intended to support any and all network address types, not just IPv4 and IPv6. It is also currently, very much in beta, being about 75% feature complete with 6-9 months work of (part-time) work left on it before it can reach version 1.0 ready. A Python 3.0 version is also planned for release soon. In answer to various specific issues raised about netaddr. The need for separate IP and CIDR classes is set out in the FAQ page :- http://code.google.com/p/netaddr/wiki/NetAddrFAQ FYI, AddrRange is a (not yet abstract) base class with a start and end address covering the shared functionality of 3 subclasses (IPRange, CIDR, Wildcard) which should all interchangeable (within reason). It is also supports generic address (Addr objects) rather than just IP specific ones. Base 2 slices is not always the best way of expressing groups of network hosts, they are *one* way. With netaddr, I wanted to avoid the 'super object' syndrome that seems to dog virtuall all other existing efforts out there, and not only those in Python. In any event confusion will hopefully be dealt with as the docs improve. As for performance, netaddr's current speed for certain operations areas may be slower than other implementations but the optimisation phase of development hasn't even begun. There are loads more features to add and get working before that starts. One point I will make is on licensing. netaddr is BSD, so you can do whatever you want with it and contribute as you see fit. At the present time, contributing to ipaddr for anyone outside Google seems like the software equivalent of climbing Mount Everest! Even if I personally wanted to contribute to this particular project's efforts, having to sign the individual CLA would automatically preclude me from doing so. This is a *major* sticking point. Regardless of whatever decision is taken, netaddr will always be available as long as it has a user base, either as built in, optional extra or as a part of some wider standardisation effort. _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue3959> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
