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

[R. David Murray]

On Wed, 3 Jun 2009 at 03:42, Mike Pennington wrote:
> 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.

I think this hits the nail on the head.  Rather than network engineers
having a less precise understanding of IP, what we have is two different
sets of domain requirements.  Network engineers deal with networks, with
IPs being a necessary special case.  Others deal with host addresses,
with networks as an additional data type.

Both approaches are valid, but lead to different design decisions.
I don't see any reason why both needs cannot be met by a common API,
but I'm wondering if any existing package is going to incorporate both
approaches satisfactorily.  As another poster said, each package that gets
written solves the problems that the particular author(s) needed solved.

Since it seems clear that ipaddr does not address the needs of the
"other half" of the user base, and that its API considered on its own
does have design flaws that would be difficult to fix in a backward
compatible fashion (eg: returning strings from __getitem__), I withdraw
my support for keeping it in 3.1.

--David