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

Steven D'Aprano steve at pearwood.info
Mon Sep 28 17:13:41 CEST 2009

On Mon, 28 Sep 2009 01:57:04 pm Martin v. Löwis wrote:

>> Finally, to Stephen's point about seeing the other side of the >> argument, I wrote this offlist a week ago: >> >> I understand what you're saying, I understand that >> 192.168.1.1/24 isn't a network, > > But you still want to treat it as one. > > 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?

It's fairly obvious to me why the library should support 192.168.1.1/24 as an input, and return a network. End-users are likely going to enter such things (e.g. 82.94.164.162/29), as they will know one IP address in the network (namely, of one machine that they are looking at), and they will know the prefix length (more often, how large the network is - 8 or 16 or 32). So very clearly, end users should not be required to make the computation in their heads.

Thank you Martin.

I had somehow -- justifiably or not, it doesn't matter -- got the impression from Peter off-list that this was not a use-case he gave any credence to, but of course the current API supports it, which confused me no end.

I'm not sure that just because the user enters '82.94.164.162/29' into the UI, the API must accept it. As Jean-Paul suggests, the issue of dealing with user-input is different from API aimed at developers. There are at least three options:

(1) The status quo: IPv4Network accepts the host address plus mask, and returns an object which behaves like a network but remembers the host address.

(2) Like (1), but the address is normalised to the canonical network address (which if I've calculated it correctly should be '82.94.164.160').

In this case, whether the user enters '82.94.164.162/29' or '82.94.164.169/29', the network returned will be the same. If the developer wants to save the host address as well as the network for some reason, he should store the host address as a separate object.

(3) Like (2), except the constructor is strict and only accepts the canonical network address, and will raise an exception if given '82.94.164.162/29'. This may require at least one helper function to calculate the network/mask from the address/mask.

The PEP now states:

"It should be understood that, above all, this module is designed with the network administrator in mind. In practice, this means that a number of assumptions are made with regards to common usage and the library prefers the usefulness of accepted practice over strict adherence to RFCs. For example, ipaddr accepts '192.168.1.1/24' as a network definition because this is a very common way of describing an address + netmask despite the fact that 192.168.1.1 is actually an IP address on the network 192.168.1.0/24. ..."

which nicely explains why (3) is not used, but doesn't explain why (1) should be preferred over (2).

-- Steven D'Aprano

More information about the Python-Dev mailing list