On Sun, Oct 27, 2019, at 03:24, Steve White wrote:
> Yes, there are several options, but they all involve an extra layer
> that detracts between the interface I am building and my user's code.
> In this situation, the objects being used as keys are conceptually the
> unique entities that the user d
Steve White writes:
> ...
> A little documentation would have saved me personally days of work.
> It would be helpful to know:
> * under what conditions can one expect a "perfect hash", that is,
> one where __eq__() will never be called?
Never expect it: keys with different hash values may end
Steve White writes:
> Yes, there are several options, but they all involve an extra layer
> that detracts between the interface I am building and my user's code.
Do the wrapping behind the application interface.
And in a private email you told me that this is for a very
special case -- which lik
On Mon, 28 Oct 2019 at 10:01, Steve White wrote:
>
> Hi Chris,
>
> I'm afraid you've missed my point. As I said in the initial post, I
> have read the documentation.
>
> I think the documentation does not adequately explain how the
> hashtable (or hashtables generally) work internally.
As stated
On Mon, Oct 28, 2019 at 7:34 PM Steve White wrote:
>
> Hi Chris,
>
> I'm afraid you've missed my point. As I said in the initial post, I
> have read the documentation.
>
> I think the documentation does not adequately explain how the
> hashtable (or hashtables generally) work internally.
>
> I th
Hi Chris,
I'm afraid you've missed my point. As I said in the initial post, I
have read the documentation.
I think the documentation does not adequately explain how the
hashtable (or hashtables generally) work internally.
I think that in fact, if __hash__() returns a unique integer for each
key
On 2019-10-20 19:31:43 +0200, Steve White wrote:
> The point is, I don't think __eq__() is ever called in a situation as
> described in my post,
This is only guaranteed if the hash is actually stored within the dict.
This seems to be the case in the CPython implementation, but there are
other ways
On Sun, Oct 27, 2019 at 6:26 PM Steve White wrote:
> As near as I can tell, returning the id() in __hash__() results in a
> perfect hash key. I really want to know if that is true.
> Because if it is true, any further layer is simply covering for a
> failing in the documentation.
Only if your __
Hi,
Yes, there are several options, but they all involve an extra layer
that detracts between the interface I am building and my user's code.
In this situation, the objects being used as keys are conceptually the
unique entities that the user deals with, even if their data is
non-unique. And I do
On Sat, Oct 19, 2019, at 07:31, Steve White wrote:
> Hi,
>
> I have an application that would benefit from object instances
> distinguished by identity being used in dict's and set's. To do this,
> the __hash__ method must be overridden, the obvious return value being
> the instance's id.
>
> Thi
Hi Dieter,
I'm sure that 99% of all use of 'dict' in Python is exactly this. The
vast majority of my own Python code is such, and that is as it should
be.
Here I have an application where I can do something really cool and
useful, by keying on identity. The built-in Python structures are
pretty
Steve White writes:
> Regarding my question
> "Is there some fatal reason that this approach must never be
> used, besides the lack of documentary support for it?"
> If finally dawned on me that there is a use-case for containers that
> would preclude using object identity for keys. That is,
Regarding my question
"Is there some fatal reason that this approach must never be
used, besides the lack of documentary support for it?"
If finally dawned on me that there is a use-case for containers that
would preclude using object identity for keys. That is, if the object
is to be seriali
-- Forwarded message -
From: Steve White
Date: Sun, Oct 20, 2019 at 11:38 PM
Subject: Re: keying by identity in dict and set
To: Peter Otten <__pete...@web.de>
Hi Peter,
Thanks, that does seem to indicate something.
(But there was no need to define a class... you'r
Steve White wrote:
> On Sun, Oct 20, 2019 at 7:57 PM Peter Otten <__pete...@web.de> wrote:
>>
>> Steve White wrote:
>> >
>> > The point is, I don't think __eq__() is ever called in a situation as
>> > described in my post, yet the Python documentation states that if
>> > instances are to be used a
On Mon, Oct 21, 2019 at 4:33 AM Steve White wrote:
> The options for following the documentation in this situation are:
> either subject users to unfamiliar, custom-made container classes, or
> give up the semantics of the "==" operator.
>
> It seems so unnecessary, given (my understanding of) how
On Sun, Oct 20, 2019 at 7:57 PM Peter Otten <__pete...@web.de> wrote:
>
> Steve White wrote:
> >
> > The point is, I don't think __eq__() is ever called in a situation as
> > described in my post, yet the Python documentation states that if
> > instances are to be used as keys, it must not be used
Steve White wrote:
> Hi Peter,
>
> Yes you are right. In fact, I shouldn't even have mentioned the
> hash() function... it came from a line of reasoning about what an
> implementation might do if very large integers were returned by
> __hash__(), and some remarks about the value returned by id()
Hi Peter,
Yes you are right. In fact, I shouldn't even have mentioned the
hash() function... it came from a line of reasoning about what an
implementation might do if very large integers were returned by
__hash__(), and some remarks about the value returned by id() applied
to small integers.
The
Steve White wrote:
> Hi Chris,
>
> Yes, I am aware of the hash of small integers. But I am not keying
> with small integers here: I am keying with id() values of class
> instances.
The id() values /are/ smallish integers though.
(I would guess that this is baked into the CPython source, but di
Hi Chris,
Yes, I am aware of the hash of small integers. But I am not keying
with small integers here: I am keying with id() values of class
instances.
Precisely what my example shows is that the dict/set algorithms in
fact *never* call __eq__, when the id() of a class instance is
returned by __
On Sun, Oct 20, 2019 at 3:08 AM Steve White wrote:
> It would appear that if __hash__ returns the id, then that id is used
> internally as the key, and since the id is by definition unique, no
> key collision ever occurs -- at least in every Python implementation
> I've tried. It also seems that,
Hi,
I have an application that would benefit from object instances
distinguished by identity being used in dict's and set's. To do this,
the __hash__ method must be overridden, the obvious return value being
the instance's id.
This works flawlessly in extensive tests on several platforms, and on
23 matches
Mail list logo
