[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure
report at bugs.python.org
Tue Jun 2 04:03:10 CEST 2009
Clay McClure <clay at daemons.net> added the comment:
On Mon, Jun 1, 2009 at 7:51 PM, pmoody <report at 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 <report at bugs.python.org>
<http://bugs.python.org/issue3959>
_______________________________________
More information about the Python-bugs-list
mailing list