[Python-Dev] PEP 3144 review.

[Mark Dickinson]

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