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

Nick Coghlan ncoghlan at gmail.com
Sun Sep 27 22:34:51 CEST 2009

Peter Moody wrote:

Steven D'Aprano wrote:

Could you explain what benefit there is for allowing the user to create network objects that don't represent networks? Is there a use-case where these networks-that-aren't-networks are something other than a typo? Under what circumstances would I want to specify a network as 192.168.1.1/24 instead of 192.168.1.0/24? that pretty flatly states that my use case is invalid.

Looks like Steven was asking you to explain your use case to him rather than stating that it didn't exist. (although I will grant that the network definition use case had been well covered, I will also grant that these threads have been somewhat interminable and I can easily understand someone missing those use case definitions - the example of being able to define a network given only the network mask and the IP address of the host running the current application should be mentioned explicitly in the PEP)

1) if strict=False, mask off the bits described by the netmask when creating an IPNetwork, such that the host bits are always 0. I haven't heard anyone suggest auto-masking bits, but otherwise that would be strict=True.

Actually, that's exactly what I suggested in this thread - that IPNetwork should lose the "ip" property and that the definition of "network equality" should be based on the network address not on the host address that happened to be used when constructing the network object.

The part that is confusing with the current library implementation is the fact that we can have two IPNetwork objects, supposedly describing the same network, compare unequal because they happened to be defined differently. It would be analagous to having "Decimal('3.0') != Decimal('3.00')".

2) add a single new function:

def parsenetandaddr(s): return (IPNetwork(s), IPAddress(s.split('/')[0])) I've only heard talk of new classes and new methods, not new constructor functions. In fact, when I asked for explicit clarification of what was required, a new constructor function "ala IPAddress and IPNetwork (so the current classes remain largely the same and the various constructors enforce certain restrictions)", I was told, no, a new object AddressWithMask was actually required. I've no problem with a constructor like this, but this is not what people have been asking for.

No, AddressWithMask was merely defined as a concept separate from an IP Network to indicate how the current IPNetwork class was being overloaded with two distinct concepts and hence exhibiting unnecessary behavioural quirks.

The use case for "given a netmask and an arbitrary host on that network, give me the appropriate IPNetwork object" has been well established by this discussion (although still isn't particularly well described even in the latest PEP update). This is what "strict=False" covers, and I'm now happy that practicality means this is appropriate default behaviour for the IPNetwork constructor.

The use case for "create an IPNetwork object and have it remember which particular host address was used to define it" is still not established at all.

It is this latter use case which is covered by the AddressWithMask concept (which may be perfectly validly represented as a simple IPNetwork/IPAddress tuple, which was also mentioned when the concern was first raised).

The main concern here is to take the "AddressWithMask" behaviour off the IPNetwork objects. It interferes with their interpretation as descriptions of networks because they maintain a piece of irrelevant state and pay attention to it in comparison operations.

Cheers, Nick.

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

More information about the Python-Dev mailing list