Pre-PEP: __hashable__

[Chad Netzer]

On Wednesday 11 December 2002 12:42, you wrote:
> |>     key = cPickle.dumps(dct)
> |>     key = pprint.pformat(dct)
> |
> |Indeed, I've considered using the first on rare occasions (and
> | then always reconsidered and did something more sane. :)
> |I won't even dignify the second one. :)
>
> This seems strange.  I do not consider either of these ideas to
> be particularly bad ones.  Each produces a reversible,
> recursively immutable, object that works perfectly well as a
> dictionary key.

I agree that they aren't a bad idea, and in fact are very useful 
when you need a key made from a mutable object.  However, I meant 
that if I were really trying to use mutable objects as keys, I'd 
reconsider, and look for anothermethod to accomplish my goal, if 
possible.

Of the two proposed methods, I much prefer the use of pickle 
because you could then reconstruct your objects from the key.  I 
would actually find this useful because I could turn my object into 
a key, and drop my references to the original object (to help 
ensure that I don't mutate it).  Then later, when I do need to 
mutate it again, I unpickle it and create a new key.  That may have 
it's uses.

Of course, not everything is pickleable, and for those cases, the 
second approach would be useful for generating keys from a mutable 
object.  However, I am skeptical of your claim that it can be used 
to make an identity function.  It wouldn't be able to reconstruct 
instances, classes, files, and many other python objects. (which is 
why it works where pickle doesn't).

> I would prefer either of these by a HUGE margin to all the
> shenanigans being discussed with .__hashable__() methods, custom
> ImmutableList objects, and the like.  All of those seem ugly,
> heavy, and wholly unnecessary.

Yeah, I'm not decided for the __hashable__() idea, although I would 
be willing to think about it if a PEP was made.

-- 
Bay Area Python Interest Group - http://www.baypiggies.net/

Chad Netzer
cnetzer at mail.arc.nasa.gov