On Mon, Sep 28, 2009 at 3:42 PM, Dj Gilcrease <digitalxero at gmail.com> wrote:
> On Mon, Sep 28, 2009 at 8:04 AM, Daniel Stutzbach
> <daniel at stutzbachenterprises.com> wrote:
>> On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>>
>>> I should note that I've softened my position slightly from what I posted
>>> yesterday. I could live with the following compromise:
>>>
>>> >>> x = IPv4Network('192.168.1.1/24')
>>> >>> y = IPv4Network('192.168.1.0/24')
>>> >>> x == y # Equality is the part I really want to see changed
>>> True
>>> >>> x.ip
>>> IPv4Address('192.168.1.1')
>>> >>> y.ip
>>> IPv4Address('192.168.1.0')
>>
>> With those semantics, IPv4Network objects with distinct IP addresses (but
>> the same network) could no longer be stored in a dictionary or set. IMO, it
>> is a little counter-intuitive for objects to compare equal yet have
>> different properties. I don't think this is a good compromise.
>
> Thats not true, the patch I submitted
> http://codereview.appspot.com/124057 still allows the networks to be
> included in a set or as a dict key
>
>>>> net1 = IPNetwork("10.1.2.3/24")
>>>> net2 = IPNetwork("10.1.2.0/24")
>>>> print hash(net1) == hash(net2)
> False
>>>> print net1 == net2
> True
In that case, your patch breaks the rather fundamental rule that
Python objects that compare equal should have equal hash. :-)
Relying on hashes to be distinct isn't safe.
Mark
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4