First off just to make your life easier in the future the DebugView
property on the expression is much better than the other view - it produces
something that looks like C#.
Ok, I think the types are actually different and the LHS is succeeding on
one of ==, <, or >. I say that because in MakeSortComparisonRule we do:
if (xType == yType && cTarget != SlotOrFunction.Empty) {
And if they were both old instances we'd do the ShouldCoerce check (which
would be true) and we'd generate the code which looks like the list.sort()
case. You can check xType and yType in the debugger. Better yet you can
drill into the meta objects in the types array and see the actual values the
rule is being created for.
The problem type I think is xType and it's probably some IronPython runtime
type (because it defines __eq__ as well as op_LessThan and op_GreaterThan).
But I have no guesses as to what it is - every type I tried still went down the
__cmp__ path.
So look at xType and those methods... If it somehow is really an OldInstance
then something really strange is going on and it'd be interesting to see if
xType
and yType are somehow different when they should be the same.
> -----Original Message-----
> From: ironpython-users-bounces+dinov=microsoft....@python.org
> [mailto:ironpython-users-bounces+dinov=microsoft....@python.org] On
> Behalf Of Slide
> Sent: Friday, March 30, 2012 5:08 AM
> To: ironpython-users@python.org
> Subject: Re: [Ironpython-users] Why does this happen?
>
> Here's the expression for my case
>
> {IIF(CallSiteBinder(Convert($arg0).__eq__(Convert(Unbox($arg1)))), 0,
> IIF(CallSiteBinder(op_LessThan(Convert($arg0),
> Convert(Unbox($arg1)))), -1,
> IIF(CallSiteBinder(op_GreaterThan(Convert($arg0),
> Convert(Unbox($arg1)))), 1, IIF((Not(((coerceResult =
> Convert($arg0).__coerce__(value(IronPython.Runtime.CodeContext),
> Convert(Unbox($arg1)))) Is OldInstance)) AndAlso ((coerceTuple =
> ValidateCoerceResult(coerceResult)) != null)), {var callres; ... },
> Convert(Convert($arg0).__cmp__(value(IronPython.Runtime.CodeContext),
> Convert(Unbox($arg1))))))))}
>
> Here is the expression for the List.sort case
>
> {IIF((Not(((coerceResult =
> Convert($arg0).__coerce__(value(IronPython.Runtime.CodeContext),
> Convert($arg1))) Is OldInstance)) AndAlso ((coerceTuple =
> ValidateCoerceResult(coerceResult)) != null)), {var callres; ... },
> Convert(Convert($arg0).__cmp__(value(IronPython.Runtime.CodeContext),
> Convert($arg1))))}
>
> Is there more information from the DynamicMetaObject that would be helpful?
>
> Thanks for your time, I appreciate you helping out those like me who don't
> know
> much about the internals of IronPython.
>
> slide
>
>
> On Thu, Mar 29, 2012 at 10:07 PM, Dino Viehland <di...@microsoft.com>
> wrote:
> > I'm actually not sure why it would happen. The only thought I have is
> > if you're only doing one comparison, and comparing the same instance,
> > there's an object identity test which would prevent the __cmp__ call
> > from happening. But I'm guessing that's not what's happening...
> >
> > Can you put a breakpoint in PythonProtocol.Operations.cs in
> > MakeSortComparisonRule and see what's returned from the call to
> > bodybuilder.GetMetaObject? That'll give you the full expression tree
> > of the rule for doing the comparison. There's supposed to be some
> > calls to __cmp__ in there - if they're not there maybe what is will provide
> > some
> enlightenment.
> >
> >> -----Original Message-----
> >> From: ironpython-users-bounces+dinov=microsoft....@python.org
> >> [mailto:ironpython-users-bounces+dinov=microsoft....@python.org] On
> >> Behalf Of Slide
> >> Sent: Thursday, March 29, 2012 8:49 PM
> >> To: ironpython-users@python.org
> >> Subject: Re: [Ironpython-users] Why does this happen?
> >>
> >> Is Dino on vacation? He usually has good answers for these sorts of
> >> things :-) I still can't get the callsite to end up calling __cmp__
> >> like List.sort does. I'm not sure why that is the case. It looks like
> >> even the Python version of bisect has a similar issue though (it
> >> never calls __cmp__ either), so I think there is a bug somewhere.
> >>
> >> On Sat, Mar 24, 2012 at 8:51 PM, Slide <slide.o....@gmail.com> wrote:
> >> >
> >> > I am implementing a module in C#. This module does some comparison
> >> operations. One of the tests for this module has something like the
> >> following:
> >> >
> >> > class CmpErr:
> >> > def __cmp__(self, other):
> >> > raise ZeroDivisionError
> >> >
> >> > x = [CmpErr(), CmpErr(), CmpErr()]
> >> > cSharpMethod(x)
> >> >
> >> > Inside cSharpMethod is when I do the comparison. The way I am doing
> >> > the comparison is taken from how its done in List.cs
> >> >
> >> > IComparer comparer =
> >> > PythonContext.GetContext(context).GetComparer(null,
> >> > GetComparisonType(context, list));
> >> >
> >> > Then I call comparer.Compare on the two items. In List.sort, this
> >> > eventually
> >> calls the __cmp__ method if I try adding a call to x.sort() instead
> >> of cSharpMethod, but from inside cSharpMethod, __cmp__ is never
> >> called and I can't figure out why.
> >> >
> >> > Any ideas on why this might be occuring?
> >> >
> >> > Thanks,
> >> >
> >> > slide
> >> >
> >> > --
> >> > Website: http://earl-of-code.com
> >>
> >>
> >>
> >>
> >> --
> >> Website: http://earl-of-code.com
> >> _______________________________________________
> >> Ironpython-users mailing list
> >> Ironpython-users@python.org
> >> http://mail.python.org/mailman/listinfo/ironpython-users
> >
> >
>
>
>
> --
> Website: http://earl-of-code.com
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users@python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
>
_______________________________________________
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users
