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

[Markus Schaber]

Hi, Jeff,

> -----Ursprüngliche Nachricht-----
> Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> Gesendet: Sonntag, 9. August 2015 17:50
> An: Markus Schaber
> Cc: Discussion of IronPython
> Betreff: Re: [Ironpython-users] Problem with the "in" operator for
> 
> On Fri, Aug 7, 2015 at 12:47 AM, Markus Schaber
> <m.schaber at codesys.com> wrote:
> > Hi, Jeff,
> >
> > Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> >> 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.
> >
> > What to do now?
> >
> > Should I file a bug report on
> https://github.com/IronLanguages/main/issues ?
> 
> That's probably the best bet, with as minimal a reproduction as
> possible. These code generation bugs are the hardest to deal with
> because I have to page everything involved back into my brain, and
> it's an absolute knot of code to sort through. So, no promises that
> I'll get to it anytime soon. :(
> 
> - Jeff

Thank you.

I did file https://github.com/IronLanguages/main/issues/1222. It seems I did not find the right way to attach C# source files, so I had to paste it into the first comment.


Best regards

Markus Schaber

CODESYS® a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber at codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.