hashability

[James Stroud]

Carl Banks wrote:
> On Aug 11, 5:54 pm, James Stroud <jstr... at mbi.ucla.edu> wrote:
> 
>> To prevent users of one of my libraries from falling into this and
>> similar traps (which have potentially problematic consequences),
> 
> Even so, I would consider whether some of your users might, like me,
> also find this terribly useful, and if so (probably a few will unless
> they are all novices), allow them to disable or disregard this check.

I realize I left out my use. The intent of the function is to flag 
objects that will make useful keys for a persistent dictionary. The 
{C():4}[C()] example demonstrates why I want to avoid certain types of 
keys--I don't want users to do things like {C():4, C():4}, which python 
happily allows but falls apart at the level of persistence.

However, I also want to avoid isinstance() and/or type checking in order 
to allow maximal flexibility so that users don't have to work too hard 
to make their keys.

> I wouldn't call the function "hashable".  Class instances like C() are
> hashable whether you approve or not.  Something like
> "deliberately_hashable" would be a better name.

I chose "keyable".

>> Can anyone think of boundary cases I might be missing with this approach?
> 
> It is possible to redefine == operator by defining __ne__ instead of
> __eq__, at least on Python 2.5, so you should keep that in mind.

Thanks for this hint. I've already put it in.

James