[Python-Dev] PEP 3144 review. (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sun Sep 27 07:38:37 CEST 2009

Peter Moody wrote:

I again invite interested parties to continue this discussion on ipaddr-py-dev at 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 | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list