[ZODB-Dev] [BTrees] Inconsistent equality checks

[Dieter Maurer]

Tim Peters wrote at 2003-11-7 18:15 -0500:
 > [Dieter Maurer]
 > > That's a nice implementation centric explanation of what I found out.
 > >
 > > However, from a semantics point of view "OOSet" and "OOTreeSet"
 > > are two implementations of the same abstract data type.
 > > It is therefore surprising that their "keys()" result behave
 > > semantically different with respect to "==".
 > 
 > I didn't say it wasn't surprising, I pointed out that the documentation
 > (meaning the formal IReadSequence interface) promises nothing about
 > comparability of objects implementing IReadSequence -- it only promises that
 > they support __getitem__ and __getslice__.
 > 
 > So if you just want to share your surprise, no problem; if you want to say
 > it's a bug, I disagree (it's functioning as documented and designed, and
 > that comparison acts differently between the cases doesn't bother me any
 > more-- or less --than that, e.g., OOSet.keys() has an .index() method today
 > but OOTreeSet.keys() doesn't).

My main purpose for this thread has been to warn "BTrees" users
about the surprising differences between "XXSet" and "XXTreeSet"
when one tries to implement equality checks for sets implemented
by "XXSet/XXTreeSet".

  The standard Python "equality" operator implements (for historical
  reasons, as you have explained) a semantically useless check.
  Thus, who needs set equality must look for alternatives.

  One may try to implement equality of sets by equality of their "keys()".
  This works for "XXSet" but fails for "XXTreeSet".

  Some "BTrees" related documentation (I do not care enough to
  to search it) suggests that "XXSet" and "XXTreeSet" are
  both implementations of "Set" which can be used interchangeably --
  one for smaller, the other for larger sets.
  However, one has to be very careful when one replaces an
  "XXSet" by an "XXTreeSet" (because the set size became larger
  than is good for "XXSet").

-- 
Dieter