Peter Moody wrote:
> I again invite interested parties to continue this discussion on
> ipaddr-py-...@googlegroups.com. we're pushing 250 messages on PEP
> 3144 at this point; well beyond what most folks would call a "long
> open-ended discussion".
>
> anyway:
>
>> The current behaviour is confusing to me. For example:
>>
>>>>> netw1 = ipaddr.IPv4Network('192.168.1.1/24')
>>>>> netw2 = ipaddr.IPv4Network('192.168.1.0/24')
>>>>> netw1 == netw2
>> False
>>>>> list(netw1) == list(netw2)
>> True
>
> I think you're intentionally confusing yourself here. 192.168.1.1
> clearly doesn't equal 192.168.1.0, so I don't know why you'd expect
> 192.168.1.1/24 to equal 192.168.1.0/24.
No, this is exactly the "dual purpose" nature of IPNetwork that people
have been complaining about: 192.168.1.1 & 255.255.255.0 == 192.168.1.0
& 255.255.255.0, so the two objects describe the exact same network, but
the network objects don't currently respect their own netmask, instead
remembering which particular host happened to be used to derive the
network ID.
"Arbitrary network host with associated netmask" and "IP Network" are
different concepts, but the library currently uses a single class
interface (IPNetwork) for both of them.
What we're asking for is for the "ip" attribute to be removed from IP
Network, with the constructor either forgetting the host IP that was
used to derive the network address, or else only accepting the correct
network address in the constructor and providing a separate helper
function or class method to create an IPNetwork object from an arbitrary
hostname.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
