[Python-Dev] PEP 3144 review.

[Nick Coghlan]

Peter Moody wrote:
>> That is, you've rejected the idea of having:
>>
>>>>> IPv4Network(192.168.1.1/24)
>> IPv4Network(192.168.1.0/24)
> 
> yes, I and everyone have rejected that idea. this should either raise
> an  error, or do what it does now, that is, return
> IPv4Network('192.168.1.1/24')

Um, no, several people (me included) have said that defining an
IPNetwork based on its *network address* and its netmask, instead of the
arbitrary hostname.


>> as reducing functionality, presumably because the address 192.168.1.1 is
>> lost.
> 
> good guess.
> 
>> Sounds just like an Address+netmask to me, with added
>> network-like behaviour.
>>
>> Some people have requested a way of explicitly calculating a network
>> from an Address and netmask, and you've been hostile to the idea. But
>> it seems to me that your API does exactly that.
> 
> You mean the suggestion to include an IPv?Network object attribute
> with the IPv?Address objects? I thought that was dropped long ago.

No, we're talking about any way of calculating the canonical network
object given a host within that network and the netmask.

With the current incarnation of ipaddr, the way you do that is to create
an IPNetwork object with net.ip != net.network. But then you get a
bizarre artifact, in that the same network will not compare equal if it
is derived using a different IP address.

There are *3* major concepts in ipaddr:
- single address
- network (defined by network address + net mask)
- arbitrary host associated with a specific network

Since those 3 concepts are being mapped to only two classes, 3 different
ways have been proposed of handling the 3rd concept:
- a "network" attribute on IPAddress objects (rejected, largely by
consensus as far as I can tell)
- a 2-tuple containing an IPAddress object and an IPNetwork object
(rejected implicitly by your refusal to remove the .ip attribute from
IPNetwork objects)
- the current implementation, which uses an IPNetwork object with net.ip
!= net.network.

That 3rd approach would be largely OK, *except* that the current
implementation of it breaks the definition of network equality.

Currently, IPNetwork("192.168.1.0/24") != IPNetwork("192.168.1.1/24"),
despite the fact that they refer to the exact same network. I believe
that is the fundamental point of contention here.

Regards,
Nick.

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