Clay McClure <c...@daemons.net> added the comment: On Mon, Jun 1, 2009 at 7:51 PM, pmoody <rep...@bugs.python.org> wrote:
>> For an example of why 192.168.1.1 != 192.168.1.1/32, look no further >> than ifconfig: >> >> # ifconfig en0 192.168.1.1/32 >> # ifconfig en0 >> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 >> inet 192.168.1.1 netmask 0xffffffff broadcast 192.168.1.1 >> ... >> >> # ifconfig en0 192.168.1.1 >> # ifconfig en0 >> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 >> ... > > what this shows is that your copy of darwin defaults to a /24 > prefixlen; ipaddr assumes a /32 prefixlen. I don't see anything > particularly *more* intuitive with darwin, but in any event, it seems > to provide support for assuming a prefixlen when none is supplied. The example demonstrates one case where the strings '192.168.1.1' and '192.168.1.1/32' are not equivalent -- it wouldn't be hard to find other examples -- yet you seem to think that (a) this is Darwin-specific behavior, and that (b) this discrepancy is acceptable and does not constitute a design flaw. You're wrong on both fronts, since in fact all IP implementations understand classful addressing (as per RFC-791), not just Darwin, and your insistence on the equality of '192.168.1.1' and '192.168.1.1/32' means that your library is unusable in applications that pass ipaddr.IPv4 objects to ifconfig. Clay ---------- _______________________________________ 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