This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients Arfrever, christian.heimes, georg.brandl, loewis, mark.dickinson, meador.inge, ncoghlan, pitrou, python-dev, skrah, vstinner
Date 2012-08-10.08:53:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <5024CC08.5090405@v.loewis.de>
In-reply-to <1344584919.64.0.468432828178.issue15573@psf.upfronthosting.co.za>
Content
> Note that in 3.2 memoryview would return "equal" for arrays that
> simply aren't equal, if those arrays happen to have the same bit
> pattern.

This is exactly my point. If a "memoryview" has the same "memory"
as another, why are they then not rightfully considered equal?
IOW, the 3.2 behavior looks fine to me.

You apparently have a vision that equality should mean something
different for memoryviews - please explicitly state what that
view is. A mathematical definition ("two memoryviews A and B
are equal iff ...") would be appreciated.

> One way to deal with this is to demand a strict canonical form
> of format strings for PEP-3118, see msg167687.

You are talking about the solution already - I still don't know
what the problem is exactly (not that I *need* to understand
the problem, but at a minimum, the documentation should state
what the intended behavior is - better if people would also
agree that the proposed behavior is "reasonable").

For 3.3, I see two approaches: either move backwards to the
3.2 behavior and defer this change to 3.4 - this would make
it release-critical indeed. Or move forward to a yet-to-be
specified equality operation which as of now may not be
implemented correctly, treating any improvement to it
as a bug fix.
History
Date User Action Args
2012-08-10 08:53:28loewissetrecipients: + loewis, georg.brandl, mark.dickinson, ncoghlan, pitrou, vstinner, christian.heimes, Arfrever, skrah, meador.inge, python-dev
2012-08-10 08:53:28loewislinkissue15573 messages
2012-08-10 08:53:27loewiscreate