New submission from Joshua Bronson <jabron...@gmail.com>:
collections.abc.Set provides a _hash() method that includes the following in its docstring: """ Note that we don't define __hash__: not all sets are hashable. But if you define a hashable set type, its __hash__ should call this function. ... We match the algorithm used by the built-in frozenset type. """ Because Set._hash() is currently implemented in pure Python, users face having to make a potentially challenging decision between whether to trade off runtime efficiency vs. space efficiency: >>> hash(frozenset(x)) # Should I use this? >>> Set._hash(x) # Or this? The former requires O(n) memory to create the frozenset, merely to throw it immediately away, but on the other hand gets to use frozenset's __hash__ implementation, which is implemented in C. The latter requires only O(1) memory, but does not get the performance benefit of using the C implementation of this algorithm. Why not expose the C implementation via a frozenset._hash() classmethod, and change Set._hash() to merely call that? Then it would be much clearer that using Set._hash() is always the right answer. ---------- messages: 412856 nosy: jab priority: normal severity: normal status: open title: Expose frozenset._hash classmethod _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue46684> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
