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/
