> 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. _______________________________________________ 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
