[Python-Dev] Fwd: Python 3.3 can't sort memoryviews as they're unorderable

[Mark Lawrence]

On 25/10/2012 15:06, Stefan Krah wrote:
> Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
>> I can't say that this gives me a great deal of confidence. It strikes me
>> that a lot of code has been written, tested and released without having
>> anything like a requirement. For example when is any given memoryview
>> equal to or not equal to any other memoryview?
>
> A lot of documentation has been written and released as well. Use it.
> In case you don't know: If a PEP and the current documentation diverge,
> the documentation takes precedence.
>
>
> Stefan Krah
>
>

<Aussies please skip>
Thanks for completely snipping the context that I gave, it gives me the 
sense that my bodyline tactics have you on the back foot.
</Aussies please skip>

The documentation states

"__eq__(exporter) A memoryview and a PEP 3118 exporter are equal if 
their shapes are equivalent and if all corresponding values are equal 
when the operands’ respective format codes are interpreted using struct 
syntax.".

Where is the requirement that states this is all that the implementation 
provides?  In the savaged PEP 3118?  Why can't I have a situation such 
that two memoryviews that I've created that meet the criteria above 
shouldn't be tested using the other comparison operators?  I'm guessing 
that I've missed something that's blatantly obvious to everybody except 
myself.  I can't find a rationale anywhere as to why I can't subclass 
memoryviews for my code, so I can't work around what I perceive as a 
glaring deficiency.  Is it a case whereby even consenting adults aren't 
allowed?

This strikes me as so different to the Python that I've been using for 
the last 10 years that it stood out, at least to me, like a sore thumb. 
  Perhaps I need yet another visit to the opticians?

-- 
Cheers.

Mark Lawrence.