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) > 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 >
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4