On 16Mar2022 14:00, Marco Sulla wrote:
>On Wed, 16 Mar 2022 at 00:42, Cameron Simpson wrote:
>> >In this case I currently cache the value -1. The subsequent calls to
>> >__hash__() will check if the value is -1. If so, a TypeError is
>> >immediately raised.
>>
>> This will also make these values
On Wed, 16 Mar 2022 at 09:11, Chris Angelico wrote:
> Caching the hash of a
> string is very useful; caching the hash of a tuple, not so much; again
> quoting from the CPython source code:
>
> /* Tests have shown that it's not worth to cache the hash value, see
>https://bugs.python.org/issue96
On 16/03/22 6:58 pm, Chris Angelico wrote:
And Python's own integers hash to themselves,
> which isn't what I'd call "widely distributed", but which
> works well in practice.
Not exactly, they seem to be limited to 60 bits:
>>> hex(hash(0xfff))
'0xfff'
>>> hex(hash(0x1f
On Wed, 16 Mar 2022 at 00:59, Chris Angelico wrote:
>
> (Though it's a little confusing; a frozendict has to have nothing but
> immutable objects, yet it permits them to be unhashable?
It can have mutable objects. For example, a key k can have a list v as
value. You can modify v, but you can't as
On Wed, 16 Mar 2022 at 00:42, Cameron Simpson wrote:
>
> Is it sensible to compute the hash only from the immutable parts?
> Bearing in mind that usually you need an equality function as well and
> it may have the same stability issues.
[...]
> In that case I would be inclined to never raise Typ
On 16Mar2022 19:09, Chris Angelico wrote:
>On Wed, 16 Mar 2022 at 18:48, Cameron Simpson wrote:
>> This may be because the "raw" hash (in this case the int value) is
>> itself further hashed (giving more evenness) and then moduloed into the
>> finite number of slots in the dict.
>
>Not in a CPyth
On Wed, 16 Mar 2022 at 18:48, Cameron Simpson wrote:
>
> On 16Mar2022 16:58, Chris Angelico wrote:
> >On Wed, 16 Mar 2022 at 14:00, Cameron Simpson wrote:
> >> On 16Mar2022 10:57, Chris Angelico wrote:
> >> A significant difference is that tuples have no keys, unlike a dict.
> >>
> >> A hash do
On 16Mar2022 16:58, Chris Angelico wrote:
>On Wed, 16 Mar 2022 at 14:00, Cameron Simpson wrote:
>> On 16Mar2022 10:57, Chris Angelico wrote:
>> A significant difference is that tuples have no keys, unlike a dict.
>>
>> A hash does not have to hash all the internal state, ony the relevant
>> stat
On Wed, 16 Mar 2022 at 14:00, Cameron Simpson wrote:
>
> On 16Mar2022 10:57, Chris Angelico wrote:
> >> Is it sensible to compute the hash only from the immutable parts?
> >> Bearing in mind that usually you need an equality function as well and
> >> it may have the same stability issues.
> >
> >
On 16Mar2022 10:57, Chris Angelico wrote:
>> Is it sensible to compute the hash only from the immutable parts?
>> Bearing in mind that usually you need an equality function as well and
>> it may have the same stability issues.
>
>My understanding - and I'm sure Marco will correct me if I'm wrong
>
On Wed, 16 Mar 2022 at 10:42, Cameron Simpson wrote:
>
> On 12Mar2022 21:45, Marco Sulla wrote:
> >I have a custom immutable object, and I added a cache for its hash
> >value. The problem is the object can be composed of mutable or
> >immutable objects, so the hash can raise TypeError.
>
> Is it
On 12Mar2022 21:45, Marco Sulla wrote:
>I have a custom immutable object, and I added a cache for its hash
>value. The problem is the object can be composed of mutable or
>immutable objects, so the hash can raise TypeError.
Is it sensible to compute the hash only from the immutable parts?
Beari
On Sat, 12 Mar 2022 at 22:37, <2qdxy4rzwzuui...@potatochowder.com> wrote:
> Once hashing an object fails, why would an application try again? I can
> see an application using a hashable value in a hashable situation again
> and again and again (i.e., taking advantage of the cache), but what's
> th
On 2022-03-12 at 21:45:56 +0100,
Marco Sulla wrote:
[ ... ]
> So if I do not cache if the object is unhashable, I save a little
> memory per object (1 int) and I get a better error message every time.
> On the other hand, if I leave the things as they are, testing the
> unhashability of the obj
I have a custom immutable object, and I added a cache for its hash
value. The problem is the object can be composed of mutable or
immutable objects, so the hash can raise TypeError.
In this case I currently cache the value -1. The subsequent calls to
__hash__() will check if the value is -1. If so
15 matches
Mail list logo
