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 | ncogh...@gmail.com | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
