[IronPython] Operator overloading, and implicit conversion from Double to Single in operators

[Korbinian Abenthum]

Dino Viehland wrote:
> Great question. The reason why operators get treated
> differently due to things like:
>
> [2, 3] * 2.0
>
> For this call we cannot coerce the float into an int by Python
> semantics.  Compare this to:
>
> xrange(2.0)
>
> which is allowed (but in CPython issues a warning).
>
> So in general Python seems to be more restrictive on binary
> operators then it does on method calls.

Hmm. I know very little of Python, but that is a bold conclusion if 
it's only based on these two examples. :)
The second call issues a "DeprecationWarning" - the reason for why 
Python is less restrictive there seems purely historical to me.

> We've mirrored this behavior in IronPython through our support of
> .NET operator overloading. That allows us to implement the standard
> Python semantics in a manner which .NET understands - for example
> our List class implements operator * and a C# programmer could do
> someList * 3.  We then just automatically expose these operators
> out to Python in a way which Python expects - including returning
> NotImplemented if the parameters aren't compatible.

That's of course the desired behavior, but I think that to mirror this 
it'd make more sense to only distinguish between integer and floating 
point numbers, just like Python does, especially since it's rather 
cumbersome to get to floats in IronPython.
Or, to be consistent with method calls where all numbers are downcast, 
just do the same with operators and solve this with overloads: The 
Sequence multiplication can get both a multiplication operator with an 
int and one with a float. I don't know how you choose between 
overloads, but if calls with an integer argument prefer the first, and 
with a floating points prefer the second (which throws NotImplemented) 
then you're done.
But it could be that I'm still missing the big picture.

> We could look at relaxing this in the future (in particular
> for non-Python types) but I think we have bigger fish to fry
> for the immediate future - and it might just make things that
> much more confusing as well.  If it's particularly troublesome
> I'd suggest opening a feature request on CodePlex so we can
> gauge how many people it's affecting by keeping track of the
> votes.

My problem was that I couldn't figure out what I was doing wrong,
why I could still multiply my vectors with integers, and why it worked
if I called the static op_Multiply method myself - that is until you
removed exposure of static operator methods in B2.2 or B2.3 ;)
I don't have to do much vector math in my scripts, so now that I know 
how to properly workaround I can definitely live with it, but I still 
think it's a bug and that it would make sense to change it some day.

BTW thanks for fixing #16693 - I'm glad that I can use globals in 
generators again. :)

Cheers,
 Korbinian