Bah. I meant to send this to the list. (I suspect that Nick also meant to send his reply to the list.)
On Mon, Dec 27, 2010 at 12:43 PM, Mark Dickinson email@example.com wrote:
On Mon, Dec 27, 2010 at 12:23 PM, Nick Coghlan firstname.lastname@example.org wrote:
The symmetry only breaks for a class that breaks the invariant:
x == operator.index(x)
Failing to guarantee that invariant seems to violate the whole spirit of operator.index().
Agreed. (Though one also needs transitivity, symmetry, etc., of equality, since what we really need is that x == y is interchangeable with operator.index(x) == y.)
Perhaps this is what we should be documenting as the true distinguishing feature between the intended semantics of __index__ and the semantics of __int__?
Hmm. Perhaps. For me, this doesn't fully capture the intent of __index__, though.
So the semantics (ignoring performance issues for now) would become:
def range_contains(self, x) try: i = operator.index(x) except TypeError: i = x return any(i == y for y in self)
This change sounds fine to me; it would be good to have a documentation note somewhere indicating that the range implementation assumes x == index(x), though. This might belong in the range documentation, or perhaps the __index__ method documentation could indicate that some builtins might have unpredictable behaviour if the identity is violated.