On 25/10/2012 15:06, Stefan Krah wrote:
Mark Lawrence <breamore...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
