Andrew Koenig wrote: > It's still the case that evaluating a hash might be expensive the > first time you do it, so you may want to be able to test whether it > can be done and actually do it only later.
I think you're doing a lot of guess-work here. In real world situations, computing the hash is very very fast by design (at worse O(n) as you noticed before for the string case, but a very fast algorithm with a very low constant multiplier), it is done only once, and checking if the whole object is (recursively) hashable is *very* near to the actual cost of computing the hash. Simple immutable objects have simple, fast hash functions; large mutable objects use id(). An object with a very long string can be an exception, but I don't think this situation is common enough to warrant a special-case and a complication of the language. I still need to hear one good reason to have a (performance critical!) check of the *hashability* of an object, in the first place. I never ever had to do it, let alone in a critical path of my code. -- Giovanni Bajo _______________________________________________ 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
