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 <dicki...@gmail.com> wrote: > On Mon, Dec 27, 2010 at 12:23 PM, Nick Coghlan <ncogh...@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) > 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 > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
