Martin v. Löwis added the comment:

1. I STRONGLY request to take hashing out of this issue. The only further 
action that this issue can have is complete reversal of the patch, starting 
over. Now that the issue has been resolved, a NEW issue arises, namely that 
hashing is inconsistent with equality. Please re-read the original issue: the 
objective of supporting unknown formats in memoryview comparisons is achieved. 
Remember that by reopening the issue, you are blocking the release (since it's 
still a release blocker).

2. Any significant change to the 3.3.0 code base should, IMO, require an 
additional release candidate (since the release candidate really ought to be 
what is going to be released, hence the name, so NO changes between candidate 
and release). Do you really want to delay the release of Python 3.3 until 
October because of hashing of memoryview objects (which, AFAICT, only affects 
bytes objects in the standard library)?

3. I don't think memoryview objects should be hashable at all. No matter what 
definition of hashing you chose, you likely won't manage to get it consistent 
with ==. Since a memoryview compares equal with its underlying object, it 
should also hash equal.

4. (unrelated to hashing, related to the original issue) I think it will be 
possible to create non-transitive equalities, where 
A==memoryview(A)==memoryview(B)==B, yet not (A==B)

5. I'm not sure whether the hash of a memoryview will surely be constant (as it 
should): isn't it possible to create a read-only buffer for a mutable memory 
block (not PyObject), so that any hashing considering the contents will result 
in changing hashes? Or, since the hash is cached, couldn't that cause the hash 
to deviate from ==?

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15573>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to