[Python-Dev] Range __contains__ and objects with __index__ methods
dickinsm at gmail.com
Mon Dec 27 13:44:26 CET 2010
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 <dickinsm at gmail.com> wrote:
> On Mon, Dec 27, 2010 at 12:23 PM, Nick Coghlan <ncoghlan at gmail.com> 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)
> 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.
More information about the Python-Dev