Joel Hedlund wrote:
Scott David Daniels wrote:
Perhaps your hash function could be something like:
I'm not sure I understand what you're suggesting.
/Joel
Sorry, a half-thought out idea based on the fact that you wanted a
consistent hash for a varying dictionary. The given dictionary subcl
Joel Hedlund wrote:
First off, please note that I consider my problem to be solved, many
thanks to c.l.p and especially Duncan Booth. But of course continued
discussion on this topic can be both enlightening and entertaining as
long as people are interested. So here goes:
heh, nothing like a
Steven D'Aprano wrote:
On Tue, 16 Dec 2008 14:32:39 +0100, Joel Hedlund wrote:
Duncan Booth wrote:
Alternatively give up on defining hash and __eq__ for FragmentInfo and
rely on object identity instead.
Object identity wouldn't work so well for caching. Objects would always
be drawn as they ap
On Wed, 17 Dec 2008 02:10:31 +0100, Joel Hedlund wrote:
> Scott David Daniels wrote:
>> Perhaps your hash function could be something like:
>
> I'm not sure I understand what you're suggesting.
Neither am I, since you've removed the hash function which might have
given readers a clue.
*wink*
On Tue, 16 Dec 2008 14:32:39 +0100, Joel Hedlund wrote:
> Duncan Booth wrote:
>> I think you probably are correct. The only thing I can think that might
>> help is if you can catch all the situations where changes to the
>> dependent values might change the hash and wrap them up: before
>> changin
Scott David Daniels wrote:
Perhaps your hash function could be something like:
I'm not sure I understand what you're suggesting.
/Joel
--
http://mail.python.org/mailman/listinfo/python-list
Joel Hedlund wrote:
Duncan Booth wrote:
I think you probably are correct. The only thing I can think that
might help is if you can catch all the situations where changes to the
dependent values might change the hash and wrap them up: before
changing the hash pop the item out of the dict, then
Duncan Booth wrote:
I think you probably are correct. The only thing I can think that might
help is if you can catch all the situations where changes to the dependent
values might change the hash and wrap them up: before changing the hash pop
the item out of the dict, then reinsert it after the
Joel Hedlund wrote:
> I should probably do this with lists instead because I can't really
> think of a way of salvaging this. Am i right?
>
I think you probably are correct. The only thing I can think that might
help is if you can catch all the situations where changes to the dependent
value
Joel Hedlund writes:
> I'm having a very hard time explaining why this snippet *sometimes*
> raises KeyError:
>
> snippet:
>> print type(self.pool)
>> for frag in self.pool.keys():
>> if frag is fragment_info:
>> print "the fragment_info *is* in the pool", hash(frag),
>> hash(fragmen
Duncan Booth wrote:
It could happen quite easily if the hash value of the object has changed
since it was put in the dictionary. what does the definition of your
core.gui.FragmentInfo object look like?
Dunno if it'll help much, but:
class FragmentInfo(object):
def __init__(self, renderer,
Joel Hedlund wrote:
> I would very much like an explanation to this that does not involve
> threads, because I haven't made any that I'm aware of. I can't even
> understand how this could happen. How do I even debug this?
>
It could happen quite easily if the hash value of the object has chang
I'm having a very hard time explaining why this snippet *sometimes*
raises KeyError:
snippet:
print type(self.pool)
for frag in self.pool.keys():
if frag is fragment_info:
print "the fragment_info *is* in the pool", hash(frag),
hash(fragment_info), hash(frag) == hash(fragment_info)
13 matches
Mail list logo
