[Ironpython-users] Problem with the "in" operator for
jdhardy at gmail.com
Tue Jul 14 06:25:31 CEST 2015
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.
More information about the Ironpython-users