Clay McClure <c...@daemons.net> added the comment:
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
----------
nosy: +claymation
_______________________________________
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
