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

Peter Moody peter at hda3.com
Sun Sep 27 07:54:21 CEST 2009

On Sat, Sep 26, 2009 at 10:38 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

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.

what you want is strict=True, just checked in. I've been meaning to send an update to the PEP explaining why this choice was made. I'm hoping this will ameliorate your confusion.

Cheers, /peter

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia ---------------------------------------------------------------

More information about the Python-Dev mailing list