[Python-Dev] Range contains and objects with index methods (original) (raw)
Mark Dickinson dickinsm at gmail.com
Mon Dec 27 13:44:26 CET 2010
- Previous message: [Python-Dev] Range __contains__ and objects with __index__ methods
- Next message: [Python-Dev] Fwd: Range __contains__ and objects with __index__ methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 rangecontains(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. Mark
- Previous message: [Python-Dev] Range __contains__ and objects with __index__ methods
- Next message: [Python-Dev] Fwd: Range __contains__ and objects with __index__ methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]