Hi, Jeff, > -----Ursprüngliche Nachricht----- > Von: Jeff Hardy [mailto:jdha...@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.scha...@codesys.com> wrote: > > Hi, Jeff, > > > > Von: Jeff Hardy [mailto:jdha...@gmail.com] > >> 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. > > > > 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.scha...@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. _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users