[issue35548] memoryview needlessly (?) requires represented object to be hashable
Raymond Hettinger
report at bugs.python.org
Sat Dec 22 18:37:23 EST 2018
Raymond Hettinger <raymond.hettinger at 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 <report at bugs.python.org>
<https://bugs.python.org/issue35548>
_______________________________________
More information about the Python-bugs-list
mailing list