Mark, do you have thoughts on the subject?

> Perhaps another path is optionally allow hashing of memoryviews
>  (all current conditions - hashability of the original object)
>  via a parameter? Like unsafe_hash like in dataclass.

I suspect this would open a can worms and that we would regret it.

If a user intentionally creates an unsafe tool using dataclasses, they have to do so explicitly.  Built-in tools such as memoryview shouldn't cross that line (especially as a default behavior).  

Also, tools like memoryview() are implemented in C and generally have tighter requirements (thread-safety, protecting invariants, not segfaulting, etc) than pure python code that can't kill the interpreter or affect C extensions.


> I'll leave the issue up for a couple of days in case someone supports
> it, but I think this one of the rare cases where all core devs 
> would reject the feature unanimously.

I concur with Stefan.

> My particular use case involves a memory view of a readonly numpy's ndarray.

As Stefan mentioned, this could be "fixed" on the Numpy side if they thought it was a useful behavior (I suspect not).