Martin v. Löwis added the comment:
Am 31.08.12 06:14, schrieb Stefan Behnel:
> To add on Dag's comments, this essentially means that any caching of
> the hash value is dangerous
Stefan Krah is right here: the proper test (which is already
implemented) is whether the underlying object is hashable; this
is a sufficient test.
Caching of the hash is always correct, or else the hash function
is incorrect: a hash of an object must not change. If it would
change, you couldn't find the key anymore in a dictionary.
> unless it can be assured that the
> underlying buffer definitely has not changed in the meantime. There
> is no way for users to explicitly tell a memoryview to rehash itself,
> so putting it into one dict, then modifying the content, then putting
> it into another is a perfectly reasonable use case for users,
No, it's not:
d = {}
o = some_object
m = memoryview(o)
d[m] = -1
o.modify() # so that hash(m) changes
print(d[m]) # keyerror, even though m in d.keys()
> As far as I can see it, any "obvious" fix for this creates a whole
> bath tub full of worms: updating views transitively, adding new APIs,
> supporting new buffer parameters, ...
So above (in this thread): the easiest fix is to just drop hashing
support for memoryview objects. This can be extended in steps:
- support hashing if the underlying object is bytes
- support hashing if the shape is 1D "B", and the underlying object
is hashable
- support hashing if the exporter has somehow promised to not modify
the memory
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15814>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
