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

R. David Murray rdmurray at bitdance.com
Mon Sep 28 13:34:46 CEST 2009

On Mon, 28 Sep 2009 at 05:57, "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. So Python code has to make the computation, and it seems most natural that the IP library is the piece of code that is able to compute a network out of that input. Does that answer your question?

The fundamental divide here is between two behaviors.

ipaddr:

 >>> x = IPv4Network('192.168.1.1/24')
 >>> y = IPv4Network('192.168.1.0/24')
 >>> x == y
 False
 >>> x.ip
 IPv4Address('192.168.1.1')

desired:

 >>> x = IPv4Network('192.168.1.1/24')
 >>> y = IPv4Network('192.168.1.0/24')
 >>> x == y
 True
 >>> x.ip
 Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
 AttributeError: 'IPv4Network' object has no attribute 'ip'

Everything else is pretty much bikeshedding and can be dealt with. This is fundamental and Peter has indicated he will not change it.

--David

More information about the Python-Dev mailing list