Issue 13411: Hashable memoryviews - Python tracker (original) (raw)

This issue has been migrated to GitHub: https://github.com/python/cpython/issues/57620

classification

Title:	Hashable memoryviews
Type:	enhancement	Stage:	resolved
Components:	Interpreter Core	Versions:	Python 3.3

process

Status:	closed	Resolution:	fixed
Dependencies:		Superseder:
Assigned To:		Nosy List:	eric.snow, meador.inge, ncoghlan, neologix, pitrou, python-dev, skrah, vstinner
Priority:	normal	Keywords:	patch

Created on 2011-11-15 22:20 by pitrou, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name	Uploaded	Description	Edit
memhash.patch	pitrou,2011-11-15 22:20	review

Messages (10)
msg147714 - (view)	Author: Antoine Pitrou (pitrou) *	Date: 2011-11-15 22:20
This patch allows hashing of memoryviews, as discussed on python-dev.
msg147811 - (view)	Author: STINNER Victor (vstinner) *	Date: 2011-11-17 16:50
Does memory_hash() reject non-contiguous memory? _Py_HashBytes() might be reused by unicode_hash() for PyUnicode_1BYTE_KIND.
msg147812 - (view)	Author: STINNER Victor (vstinner) *	Date: 2011-11-17 16:51
Except these two minor nits, the patch looks good to me.
msg147813 - (view)	Author: Antoine Pitrou (pitrou) *	Date: 2011-11-17 16:57
> Does memory_hash() reject non-contiguous memory? It should, since it checks the strides array. > _Py_HashBytes() might be reused by unicode_hash() for PyUnicode_1BYTE_KIND. I don't really see how unicode hashing should be related to bytes hashing (even though apparently an (outdated?) test checks for that).
msg147814 - (view)	Author: Charles-François Natali (neologix) *	Date: 2011-11-17 17:55
I'm not sure that the "register" storage class specifier is still relevant with modern compilers: I'm pretty sure gcc ignores it unless -O0, and I think I've read somewhere Microsoft's compiler ignores it too.
msg147815 - (view)	Author: Antoine Pitrou (pitrou) *	Date: 2011-11-17 18:00
> I'm not sure that the "register" storage class specifier is still > relevant with modern compilers: I'm pretty sure gcc ignores it unless > -O0, and I think I've read somewhere Microsoft's compiler ignores it > too. I don't think so either. I was lazily moving the original code, but I could remove those bits.
msg148080 - (view)	Author: Roundup Robot (python-dev)	Date: 2011-11-21 19:54
New changeset 215690b782f8 by Antoine Pitrou in branch 'default': Issue #13411: memoryview objects are now hashable when the underlying object is hashable. http://hg.python.org/cpython/rev/215690b782f8
msg148082 - (view)	Author: Antoine Pitrou (pitrou) *	Date: 2011-11-21 19:57
Fixed, thanks.
msg151451 - (view)	Author: Stefan Krah (skrah) *	Date: 2012-01-17 12:59
Reopening as a reminder that it isn't fixed yet in http://hg.python.org/features/pep-3118 .
msg151955 - (view)	Author: Stefan Krah (skrah) *	Date: 2012-01-25 17:44
Done in: http://hg.python.org/features/pep-3118/rev/508d5e3c579c

History
Date	User	Action	Args
2022-04-11 14:57:23	admin	set	github: 57620
2012-01-25 17:44:39	skrah	set	status: open -> closedresolution: remind -> fixed
2012-01-25 17:44:16	skrah	set	dependencies: - Problems with Py_buffer management in memoryobject.c (and elsewhere?)messages: +
2012-01-17 12:59:40	skrah	set	messages: +
2012-01-17 12:58:03	skrah	set	status: closed -> opendependencies: + Problems with Py_buffer management in memoryobject.c (and elsewhere?)resolution: fixed -> remind
2011-11-21 19:57:02	pitrou	set	status: open -> closedresolution: fixedmessages: + stage: patch review -> resolved
2011-11-21 19:54:08	python-dev	set	nosy: + python-devmessages: +
2011-11-17 18:00:57	pitrou	set	messages: +
2011-11-17 17:55:56	neologix	set	nosy: + neologixmessages: +
2011-11-17 16:57:46	pitrou	set	messages: +
2011-11-17 16:51:20	vstinner	set	messages: +
2011-11-17 16:50:59	vstinner	set	nosy: + vstinnermessages: +
2011-11-16 03:36:45	eric.snow	set	nosy: + eric.snow
2011-11-15 22:26:44	meador.inge	set	nosy: + meador.inge
2011-11-15 22:20:43	pitrou	create