On Thu, Mar 17, 2011 at 2:35 PM, Robert Kern <[email protected]> wrote:
> On Wed, Mar 16, 2011 at 15:21, Mark Wiebe <[email protected]> wrote: > > > That sounds like a good fix to me. Whenever objects compare equal, they > > should hash to the same value. > > There is a limit to how far we can actually satisfy this requirement. > For the implementation of np.dtype.__eq__(), we coerce the other > argument to a dtype object. > > [~] > |1> np.dtype(int) == int > True > > [~] > |2> np.dtype(int) == 'i4' > True > > [~] > |3> hash(int) != hash('i4') > True > > > As long as we define np.dtype.__eq__() in that way, we cannot satisfy > the requirement. The best we can do is make sure that for all true > dtype objects, if they compare equal then they hash equal. So you > could make a well-behaved dict with true dtypes as keys, but not > dtypes and "dtype-coercable" objects. > Dtypes being mutable looks like a serious bug to me, it's violating the definition of 'hashable' given here: http://docs.python.org/glossary.html#term-hashable. This can be used to make an impossible situation: >>> t = np.dtype('i4,i4') >>> d = {t : 3} >>> t.names = ('a','b') >>> d[t] = 4 >>> d {dtype([('a', '<i4'), ('b', '<i4')]): 3, dtype([('a', '<i4'), ('b', '<i4')]): 4} -Mark
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
