Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:
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). ---------- nosy: +mark.dickinson, rhettinger _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35548> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
