Fix complex.__new__

[BCSharp]

A thought: move TryToFloat to PythonOps?

[slozier]

A thought: move TryToFloat to PythonOps?

Could be an idea but we should probably check if it would be useful outside of the float/complex constructors. For example, in the constructors __float__ takes precedence, but in method calls it doesn't:

class myfloat(float):
    def __float__(self):
        return 1.0

assert float(myfloat(0.0)) == 1.0
assert abs(myfloat(0.0)) == 0.0

[slozier]

I guess these cast is where testing fails. The BigInteger to double cast returns infinity instead of overflowing. There's a MathUtils.ToFloat64 that throws (but we should consider a helper at the ipy level so we can match the error message).

[BCSharp]

Indeed. The fast track just cut too many corners. __float__ and __complex__ on int do it correctly, with a call to MathUtils.ToFloat64. Funny thing, I started working on complex.__new__ as a spin-off from an investigation whether int.__complex__ can be safely removed (it can, assuming that complex.__new__ works correctly) and then completely forgot about that.

I like the idea of our own helper class with a Python-specific error message.

[BCSharp]

I looked into the CPython's code and roughly speaking the functionality of TryToFloat resides inside PyNumber_Float, except that the latter also does string parsing, so I suppose is more or less equivalent to NewFloat. PyNumber_Float is used in a few places but it seems that apart from of the float and complex constructors, only to parse a string. So I suppose no need to move TryToFloat to PythonOps.

[slozier]

Looks good to me!