Andrew Koenig writes:
> 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.
Indeed... side effects are the primary concern.
A __hash__ method with side effects is not formally prohibited in the
documentation but nevertheless, a __hash__ which is not idempotent is
an abomination.[1] Thus, there is no need for a test of whether __hash__
will succeed: just try it.
Both calling and iterating are well-known to have irreversable side
effects in many commonly-used callables/iterables. Thus it would be nice
to have a test other than invocation to see whether the object is
"intended to work". Obviously, an object "intended to work" may still
fail: the file system being iterated over could generate hardware errors,
or the function supplied might raise a TypeError when invoked with the
particular signature you use. But at least it's willing to try... you
can identify those cases where an integer was accidentally provided
instead of the intended callable/iterable.
Personally, I don't care whether the test is spelled "callable(x)" or
"hasattr(x, '__call__')" (and similarly for iterable), so long as it
is documented.
-- Michael Chermside
[1] I subtlely switched language from "side effect free" to "idempotent"
here because caching *IS* acceptable in __hash__ mehtods. If you're
not paying close attention I probably got away with it. Then I went
and spoiled it with a footnote.
_______________________________________________
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
