Re: [Python-Dev] Issues with Py3.1's new ipaddr
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, \m
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
R. David Murray <rdmurray@bitdance.com> wrote:
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.
I wonder if part of the problem is the name of the module. Just from "ipaddr", I'd expect it to deal with host addresses (what I think of as an IP address) and would probably approach its use with the wrong expectations. I could see frustration and irritation following from that. If the module was called "networks" instead of "ipaddr", it might help. Bill
On Wed, Jun 3, 2009 at 11:16 AM, R. David Murray <rdmurray@bitdance.com> wrote:
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.
It has been brought to my attention that my use of the word "imprecise" may have been construed as an insult. For that I apologize. That was not my intent. I am sure that your understanding of IP in your domain (network engineering) is as good or better than mine in my domain (UNIX administration). That is not the point I was arguing. Had you said that thinking of addresses as having netmasks is a useful mental model, I would have agreed with you wholeheartedly. To me, this is similar to thinking of voltage as pressure. Instead, you said (or at least implied) that addresses in fact do have netmasks, which I think is technically an imprecise way of describing how the technology works. To me, that would be like building a voltmeter calibrated in pascals. As another poster has commented, I think the name of the module is the source of some confusion. While I see the validity of your use case, that is not the use case I had in mind for a module named "ipaddr". In any case, I think with some enhanced documentation and maybe some class name changes, we can clarify ipaddr's API and strive to make it support both use cases. Your continued input will be invaluable as we move forward with the PEP. Clay
participants (4)
-
Bill Janssen -
Clay McClure -
Mike Pennington -
R. David Murray