[Ironpython-users] Problem with the "in" operator for

[Jeff Hardy]

On Thu, Jul 9, 2015 at 11:50 PM, Markus Schaber <m.schaber at codesys.com> wrote:
> Hi, Ivan,
>
> Von: Ivan Pozdeev [mailto:vano at 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