On 7/23/06, Andrew Koenig <[EMAIL PROTECTED]> wrote: > > But you've just pointed out that they're *not* > > the same kind of concept, no matter how much > > you might wish that there were. > > > The only way to make hashability testable at > > less cost than attempting to do it would be > > to have a separate __is_hashable__ method for > > that purpose, which would recursively test > > contents when necessary. > > This issue started out as a question of side effects; from an architectural > viewpoint, I consider performance to be less important because side effects > are likely to affect correctness. > > So I don't particularly care whether testing for hashability is less > expensive than trying to do the hash. What I do care about is being able to > determine whether an object has a particular property without having to > worry about whether I might change the state of the system in whatever ways > are necessary to compute that property. > > This question is probably sharpest for callability, because it is clear that > evaluating foo() might do anything at all, and sometimes I want to control > when that anything happens. > > Nevertheless, I don't agree that testing hashability has to be as expensive > as computing the hash. As a simple example, one can see instantly that even > a very long string is hashable, even though computing the value of the hash > might take a long time if the string is large.
I propose to take the same approach as for callable: if it has __hash__ we consider it hashable even though the hash may fail (e.g. if it's a tuple containing an unhashable object). This is roughly equivalent to the usefulness of callable: the call may still fail if the signature doesn't match. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
