A rational proposal

[Mike Meyer]

Actually, I was misremembering how Decimal worked - it follows the rule you suggest:

float() + Decimal() fails with a TypeError
float() + float(Decimal()) works fine

And I believe Decimal's __float__ operation is a 'best effort' kind of
thing, so I have no problem with Rationals working the same way.

Actually, I suggested that:

float() + Rational() returns float

You're suggesting that the implicit conversion to float not happen
here, and the user be forced to cast it to float? And you're saying
Decimal does it that way.[

That's good enough for me.

<mike

 

[Nick Coghlan]

Actually, I suggested that:

float() + Rational() returns float

You're suggesting that the implicit conversion to float not happen
here, and the user be forced to cast it to float? And you're saying
Decimal does it that way.[

Yup.

I had another look at PEP 327 (the section on implicit construction) and the
reasoning that got us to that behaviour wasn't quite what I thought. However, I
think the point still holds for Rational - the conversion often won't be exact
in either direction, so it's OK for Python to ask the programmer to confirm that
they really want to make the conversion.

I think adding subsections modelled on PEP 327's "Explicit construction",
"Implicit construction" and "Python usability" would be a big plus for the new
Rational PEP. The layout Facundo used makes it obvious that issues of playing
well with other types have been considered properly.

Cheers,
Nick.