Instead of the proposals like "hash.from_iterable()", would it make sense
to allow tuple.__hash__() to accept any iterable, when called as a
classmethod? (And similarly with frozenset.__hash__(), so that the fast C
implementation of that algorithm could be used, rather than the slow
collections.Set
[email protected] writes:
> Instead of the proposals like "hash.from_iterable()", would it make sense
> to allow tuple.__hash__() to accept any iterable, when called as a
> classmethod?
[...]
> Would this API more cleanly communicate the algorithm being used and the
> implementation, while
On Wed, Jan 04, 2017 at 04:38:05PM -0500, [email protected] wrote:
> Instead of the proposals like "hash.from_iterable()", would it make sense
> to allow tuple.__hash__() to accept any iterable, when called as a
> classmethod?
The public API for calculating the hash of something is to call the
Couldn't you add __hash__ to collections.abc.Iterable ? Essentially,
expose __hash__ there; then all iterables automatically have a default hash
that hashes their ordered contents.
On Wednesday, January 4, 2017 at 7:37:26 PM UTC-5, Steven D'Aprano wrote:
>
> On Wed, Jan 04, 2017 at 04:38:05PM -
