Since Python 2.7 and 3.1 have not yet shipped, I hope it's not too late 
to
continue this discussion. I have no vested interest in either ipaddr or
netaddr, but I am interested in seeing a well-designed and usable IP 
address
library included in the stdlib.

From reading the comments in this issue, it seems most of the discussion
focused on netaddr's API. There seems to have been little discussion 
about
the merits of ipaddr's API, which is unfortunate given that ipaddr is 
the
library being included in the stdlib. There was some technical 
discussion on
the ipaddr and netaddr lists, but it amounted to each developer 
defending his
library, and neither party seemed willing to compromise on key design
decisions. At the end of the reconciliation period, ipaddr looks much 
the
same as it did before, albeit with prettier indentation.

When looking for an IP address library for use in a network scanning and
discovery application I wrote last year, I decided against ipaddr 
because of
its conflation of address and network -- it seems strange to me to have 
one
class modeling both concepts.

After reading the technical discussion on the ipaddr and netaddr lists, 
it is
clear to me that ipaddr's designers have a somewhat limited 
understanding of
IP addressing, and have not designed an API that articulates IP concepts
particularly well. For example, see pmoody's earlier comments in this 
ticket:

> all addresses have a subnet, even if its an implied /32

This is not only incorrect, but it demonstrates a deep misunderstanding 
of
how IP works. IP addresses most certainly do not have a "subnet", or a 
mask
of any sort. An IPv4 address is simply a 32-bit number.

IPv4 *networks* have masks, of course, hence the name "netmask". These
network masks are used by the routing process to lookup the next hop (or
directly connected network) for an IP datagram by matching the 
datagram's
destination address against the networks and masks defined in the 
routing
table.

> specifying a network as ("1.1.1.0", "1.1.1.255") seems a lot more
> off-putting than "1.1.1.0/24".

Since networks are commonly represented in at least three forms, the API
should support at least these:

CIDR/prefix notation: "192.168.1.0/24"
address+mask notation: "192.168.1.0/255.255.255.0"
range notation: "192.168.1.0-192.168.1.255"

> I guess I don't see the utility in an address range of .1 - .22 
> (or something arbitrary, something which doesn't fall on a power-of-2
> boundary); when dealing with ranges of addresses, i've always only 
> wanted to/needed to manipulate sub-networks of addresses.

This statement demonstrates an extremely narrow view of the problem 
domain.
Access lists and DHCP pools are two common examples of where arbitrary
address ranges are useful.

At least three concepts deserve first-class treatment in any meaningful 
IP
address library:

* addresses
* ranges of addresses
* networks

To conflate these is a mistake.

My hope is that now that a library has been selected, it can be improved 
before Python 2.7 and 3.1 ship. Now is the best time to make
backwards-incompatible API changes; once ipaddr ships with the stdlib, 
we're
stuck with it. If it remains as-is, it will be deadweight for those app
developers like myself who prefer an API that more accurately reflects 
the
problem domain.

To this end, now that ipaddr is moving to Python stdlib, will Google's
contributor license agreement restriction be lifted? I would like to
contribute, but have not been able to secure a corporate CLA from my
employer.

Cheers,

Clay