[Python-Dev] PEP 3144 review.

[Steven D'Aprano]

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