> > That would be at odds with the approach taken with
> > list.__hash__ which has to be called in order to find-out it is not
> > hashable.
> That feature of __hash__ is just an unfortunate necessity.
> It arises because hashability is sometimes a "deep"
> property (i.e. it depends on the hashability of a
> container's contents as well as the nature of the
> container itself). No such thing applies to __iter__.
This example illustrates an important point: Some object properties don't
correspond directly to the presence of a particular attribute, and can't
easily be made to do so.
In other words:
Is it callable? No problem, just check for __call__
Is it iterable? Well, you can't quite check for __iter__ because
some iterable types don't have them. Well, we can fix that problem:
Change those types so that they have __iter__ to signal that they
are iterable.
Is it hashable? That's a tough question to answer, because you
have to inspect recursively all of the object's components. So
you can't just test for __hash__; you have to call it.
To my way of thinking, callable, iterable, and hashable are the same kind of
concept, and I wish Python would provide a uniform way of finding out
whether such concepts apply to an object. That uniform way doesn't have to
be in __builtins__, but it would be nice for it to exist.
_______________________________________________
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
