> 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.