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.