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

Mark Lawrence breamoreboy at yahoo.co.uk
Thu Oct 25 17:57:22 CEST 2012

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

Thanks for completely snipping the context that I gave, it gives me the sense that my bodyline tactics have you on the back foot.

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.

More information about the Python-Dev mailing list