[Python-Dev] Issues with Py3.1's new ipaddr

Mike Pennington mike at pennington.net
Wed Jun 3 10:42:47 CEST 2009

Raymond solicited a comment from me about the design of ipaddr.  By way 
of full disclosure, I have a small competing project called pynet.

That said, I test drove ipaddr for about 30 minutes and so far like the 
big-picture API design quite a bit.  I'll specifically address Clay's 
concern about hosts vs networks, because this issue is important to me; 
I've been in the network engineering field for over 15 years, worked on 
Cisco's product development team, and held a CCIE (consider it the 
equivalent of a CPA for network engineers) for 10 years...

Clay seems to object to ipaddr's IP object because it is not the same as 
the object model used in the BSD ip stack.  Indeed, I'm one of the 
raving fans of what BSD has done for the quality of ip networking, but 
let's also consider their requirements.  BSD must approach ip networking 
from a host perspective, it is the consumer of individual IP packets and 
their payloads. ipaddr's whole point of existence is really driven 
towards the manipulation of potentially massive lists of ip addresses. 
This is no small difference in requirements, and I believe ipaddr's 
different approach makes their code much simpler for the tasks it needs 
to do.  Incorporating host addresses as a special case of a /32 IPv4 
network or /128 IPv6 network makes a lot of sense to me, in fact, I also 
chose this same object model.  Perl's NetAddr::IP does this too, it is 
considered the gold standard for perl's address manipulation module.

Whether python includes ipaddr now, later, or uses another module 
entirely does not bother me.  Whatever is included should have a very 
stable API, and major bugs should be worked out.  Documentation should 
be good enough for the average consumer, and if anything this is where 
ipaddr to be lacking a bit.

I hope that python does include something to manipulate IPv4 and IPv6 
address blocks in the future, since this is a big hole is python's 
batteries-included philosophy.  However, I'd need more time at the wheel 
of ipaddr before I could comment whether this truly is ready for 
inclusion in stdlib.

All the best,

More information about the Python-Dev mailing list