On Thu, Jul 9, 2015 at 11:50 PM, Markus Schaber <m.scha...@codesys.com> wrote: > Hi, Ivan, > > Von: Ivan Pozdeev [mailto:v...@mail.mipt.ru] > >> > As far as I can see, the "in" operator should return true if any >> > object in the enumerable is "equal" to the object given as reference: >> >> Indeed, https://docs.python.org/2/reference/expressions.html#membership-test- >> details states: >> >> For the list and tuple types, x in y is true if and only if there exists an >> index i such that x == y[i] is true. >> >> Now, to check if IronPython honors this. >> >> > assert a in (a,), 'a is in (a,)' >> > assert a in (b,), 'a is in (b,)' # this one fails... >> >> > As far as I can see via breakpoints, the Equals methods of the objects >> > are never actually called, except on the first assertion with the == >> > operator. >> >> My guess is it's cutting corners by comparing hashes instead. > > Hm, the GetHashCode() method in my example is hardcoded to return 0, and it > is not even called (at least, the breakpoint is not hit. > > There must be something more subtle...
In theory it should be creating a dynamic call site for "equals" that will handle all of the cases (except for types that have a __contains__ method) including IDMOP. Which there could very likely be a bug in how that is generated; I'm not sure the IDMOP is stuff gets excersized as much as it should. - Jeff _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
