hashability

[James Stroud]

Asun Friere wrote:
> On Aug 12, 3:32 pm, James Stroud <nospamjstroudmap... at mbi.ucla.edu>
> wrote:
> 
>> You should be more imaginative.
> 
> I'm by no means discounting that there might be some actual problem
> you're trying to solve here, but I honestly can't see it.
> 
> There really is no need to get personal about this, so rather than
> asking for a level of imagination from me, (which I apparently lack),
> please just explain to me how {one_instance_of_a_hashable_class : val,
> another_instance_of_a_hashable_class :val} is conceptually different
> {one_instance_of_class_str: val, another_instance_of_class_str: val},
> in terms of persistence.

Sorry for being a twit. This list used to be quite nice but some people 
on this list got pretty abrasive. I couldn't tell you weren't one of 
these abrasive people from your post. I stopped giving the benefit of 
the doubt many moons ago and promptly enter attack mode at the slightest 
hint of abrasiveness. My attitude probably exacerbates the problem--but 
it sure does make me feel better.


Anyway, I think the problem has been described better than I'm able, but 
once an object goes to the file system, one can not take its hash value 
for granted. It is not possible to rely on the ability to recreate any 
arbitrary object de-novo and use the recreation as a key in proxy for 
the original object. I'm after this "je ne sais pas que l'appeler" 
quality of objects to use as keys (or to generate keys) for persistent 
dictionaries. Carl Banks suggested that this quality should not be 
called "hashable", so I'm calling it "keyable".