> > I for one have gotten along quite happily without
> > ever wanting to test for hashability.
> Me too, as said elsewhere. This whole thread seems like a purely
> theoretical debate.
That may be because it has departed from its original intent.
I started the thread because I wanted to call attention to an issue: Objects
sometimes have properties that have side effects when exploited, and it can
be useful to be able to test for the presence of such properties without
evoking the side effects.
I used callable as an example, and several people responded that there was
no problem: An object should be considered callable if and only if it has a
__call__ attribute.
My response was that I felt uncomfortable about exposing the implementation
that way, and some others said it wasn't really an issue because there
weren't enough such properties to worry about. Someone suggested
hashability as another such property, to which the response was that that
also wasn't a problem: Just try doing it and see if it works. This
suggestion led to a branch about whether hashing could ever cause side
effects, and whether it might be expensive to compute the hash as a way of
testing whether it could be computed.
Most recently, someone observed that class object has __hash__ defined,
which means that to test for hashability, you have to try it; you can't just
check for the presence of __hash__. The response to that is that we could
have a convention: if __hash__ is None, then the object isn't hashable.
So now we have the corresponding question for __call__. Suppose you want to
inherit from a callable class but you don't want your own class to be
callable. Can you set __call__ to None? If that convention is adopted, it
would break the equivalence between callability and the existence of
__call__.
In other words, the current notion appears to be:
An object is callable iff it has a __call__ attribute.
An object is hashable iff its __hash__ attribute is not None.
This example only strengthens my original intuition that if it is desirable
to check whether an object has a given property, the way of doing so should
be uniform across different properties. In other words, if the notion of
checking for a property is useful, there should be a single abstraction for
doing that check.
_______________________________________________
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
