On 5 January 2017 at 00:31, Steven D'Aprano <st...@pearwood.info> wrote: > This is a good point. Until now, I've been assuming that > hash.from_iterable should consider order. But frozenset shows us that > sometimes the hash should *not* consider order. > > This hints that perhaps the hash.from_iterable() should have its own > optional dunder method. Or maybe we need two functions: an ordered > version and an unordered version. > > Hmmm... just tossing out a wild idea here... let's get rid of the dunder > method part of your suggestion, and add new public class methods to > tuple and frozenset: > > tuple.hash_from_iter(iterable) > frozenset.hash_from_iter(iterable) > > > That gets rid of all the objections about backwards compatibility, since > these are new methods. They're not dunder names, so there are no > objections to being used as part of the public API. > > A possible objection is the question, is this functionality *actually* > important enough to bother? > > Another possible objection: are these methods part of the sequence/set > API? If not, do they really belong on the tuple/frozenset? Maybe they > belong elsewhere?
At this point I'd be inclined to say that a 3rd party hashing_utils module would be a reasonable place to thrash out these design decisions before committing to a permanent design in the stdlib. The popularity of such a module would also give a level of indication as to whether this is an important optimisation in practice. Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
