On Mon, Sep 28, 2009 at 3:42 PM, Dj Gilcrease <[email protected]> wrote: > On Mon, Sep 28, 2009 at 8:04 AM, Daniel Stutzbach > <[email protected]> wrote: >> On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan <[email protected]> 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 _______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com