On 12/23/21 07:39, Stephen J. Turnbull wrote:
Hao Hu writes: > On 12/18/21 08:44, Stephen J. Turnbull wrote: > > Hao Hu writes:> > > >> For instance, if we create a caching programming interface that > > > >> relies on a distributed kv store, > > > > I would be very suspicious of using Python's hash builtin for such a > > purpose. The Python hash functions are very carefully tuned for high > > performance in one application only: equality testing in Python, > > especially for dicts. [...] > > It is pretty much the same use case as python's dictionary though, the > goal is just to generalize it to use with a distributed kv store. Sure, you know that because it's your application. But I don't know that, and it's only an example you give to justify a change to Python. The burden on you is not to argue that it works in one application; it's to argue that it works broadly enough to be worth changing a lot stuff in Python, imposing a change burden on any project that implements __hash__ for any of its classes, and for anybody who supports both pre- and post-change version of Python, they need to support both __hash__(object) and __hash__(object, salt) (probably trivial, just def __hash__(self, salt=None):, but I haven't thought about it).
Thanks for thinking about all this. Those are reasonable concerns.- The motivation of having such a discussion is indeed to figure out whether this small requirement could be crafted well enough for python's best interest.
- For the example mentioned above, I am wondering whether we could work around it like this:
- generalize the signature of __hash__(object) to __hash__(object, *args, **kwargs). In the default implementation, we discard the keyword "salt" and use the default fallback salt if the keyword is not present, otherwise we use the salt specified by the keyword.
> Another big advantage is that it is more user friendly to apply > *hash* directly on a type. Sure, that was the whole point of proposing it and nobody denies it.
👍
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DJNRQBSPZ2VBZXVKMIDPESNKK4FE2NJW/ Code of Conduct: http://python.org/psf/codeofconduct/
