Carl Banks wrote:
On Aug 11, 5:54 pm, James Stroud <jstr...@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
--
http://mail.python.org/mailman/listinfo/python-list
