On Mon, Apr 18, 2011 at 10:24 PM, William Stein <wst...@gmail.com> wrote: > ... > I think it is worth revisiting this design decision. I did a > little poking, and in Python and Cython, a class by default has a > hash, which is the location in memory of the object, e.g.,
Only so long as the class doesn't define __eq__ or __cmp__. That makes sense, because the default equality comparision in python is that two objects are equal if and only if they are the same instance. Thus, the basic assumption on hashes is not broken (equal objects should have the same hash). If a class defines a comparision, the default hash is to raise an exception > So the main issue I pointed out above, namely that SageObject has a > __hash__ defined, is really a non-issue, since that's the standard > default convention in Python anyways. No, the basic assumptions about hashes in Python are: 1. the hash of an object never changes 2. two objects that compare equal should have the same hash bad things happen if either assumption is broken (a third assumption would be that hash collisions are uncommon, but that only affects performance, not semantics). So, as you suggested in the OP, the right thing is to have the __hash__ method removed from the SageObject class, and define it for subclasses as needed (and only for immutable classes!) Note that the class Element (sage.structure.element.Element) also has a similar default definition for __hash__. Gonzalo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
