<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 5, 2017 at 10:58 AM Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 5 January 2017 at 13:28, Neil Girdhar <<a href="mailto:mistersheik@gmail.com" class="gmail_msg" target="_blank">mistersheik@gmail.com</a>> wrote:<br class="gmail_msg">
> The point is that the OP doesn't want to write his own hash function, but<br class="gmail_msg">
> wants Python to provide a standard way of hashing an iterable.  Today, the<br class="gmail_msg">
> standard way is to convert to tuple and call hash on that.  That may not be<br class="gmail_msg">
> efficient. FWIW from a style perspective, I agree with OP.<br class="gmail_msg">
<br class="gmail_msg">
The debate here regarding tuple/frozenset indicates that there may not<br class="gmail_msg">
be a "standard way" of hashing an iterable (should order matter?).<br class="gmail_msg">
Although I agree that assuming order matters is a reasonable<br class="gmail_msg">
assumption to make in the absence of any better information.<br class="gmail_msg"></blockquote><div><br></div><div>That's another good point.  In keeping with my abc proposal, why not add abstract base classes with __hash__:</div><div>* ImmutableIterable, and</div><div>* ImmutableSet.</div><div><br></div><div>ImmutableSet inherits from ImmutableIterable, and overrides __hash__ in such a way that order is ignored.</div><div><br></div><div>This presumably involves very little new code — it's just a propagating up of the code that's already in set and tuple.</div><div><br></div><div>The advantage is that instead of implementing __hash__ for your type, you declare your intention by inheriting from an abc and get an automatically-provided hash function.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hashing is low enough level that providing helpers in the stdlib is<br class="gmail_msg">
not unreasonable. It's not obvious (to me, at least) that it's a<br class="gmail_msg">
common enough need to warrant it, though. Do we have any information<br class="gmail_msg">
on how often people implement their own __hash__, or how often<br class="gmail_msg">
hash(tuple(my_iterable)) would be an acceptable hash, except for the<br class="gmail_msg">
cost of creating the tuple? The OP's request is the only time this has<br class="gmail_msg">
come up as a requirement, to my knowledge. Hence my suggestion to copy<br class="gmail_msg">
the tuple implementation, modify it to work with general iterables,<br class="gmail_msg">
and publish it as a 3rd party module - its usage might give us an idea<br class="gmail_msg">
of how often this need arises. (The other option would be for someone<br class="gmail_msg">
to do some analysis of published code).<br class="gmail_msg">
<br class="gmail_msg">
Assuming it is a sufficiently useful primitive to add, then we can<br class="gmail_msg">
debate naming. But I'd prefer it to be named in such a way that it<br class="gmail_msg">
makes it clear that it's a low-level helper for people writing their<br class="gmail_msg">
own __hash__ function, and not some sort of variant of hashing (which<br class="gmail_msg">
hash.from_iterable implies to me).<br class="gmail_msg">
<br class="gmail_msg">
Paul<br class="gmail_msg">
</blockquote></div></div>