Martin v. Löwis added the comment: > However, the format constraints are currently too restrictive, so > some memoryview comparisons that correctly returned True in 3.2 are > now also returning False. This patch fixes *those* comparisons to > once again return True.
No, it doesn't - at least not in all cases. If you compare 'b' and 'B' arrays with values in range(128), then 3.2 rightfully returned True, but will still return False under the patch. In any case, whatever the solution is (or even "whatever the problem is"), it needs to be clearly spelled out in the documentation, since it will be far from obvious. > Instead, they're being caused by memoryview returning False for any > equality comparison for a format it doesn't understand. That's > unacceptable, and is what Stefan's patch is intended to fix. I fail to see why this is unacceptable. If you don't understand the format code, you cannot know how to compare the values - you cannot even know how to compare the memory representation of the values. If the memory compares unequal, it may still be plausible that the values are actually equal (e.g. if this is a numerator-denominator representation of rationals). There are even cases where the memory comparison can compare as equal, yet the values should compare non-equal (e.g. IEEE NaNs, or relative pointers). I also think this is a *really* obscure problem: not many people use memoryview objects, very few desire to compare them for equality (most rather use them for efficient IO, and "poking" into structures), and of those, nearly nobody uses them with unsupported format codes - in particular not if "u" and "w" get implemented (since then standard Python will not have ways to create memoryview objects reasonably with unsupported codes). What specific example did you think of that regresses from 3.2? So I still fail to see why this problem can manage to block the release of 3.3 - but that's for the release manager to decide. ---------- _______________________________________ 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
