Ref: https://docs.python.org/3/reference/datamodel.html#object.__float__

One point of discussion; if __float__ is not present then Python will call __index__ as a fallback (and expect an int which it will promote to a float). The behaviour is neatly summarised here.

We looked at adding the conversion fallback behaviour to improve Python compatibility but found that it added enough complexity that we were questioning it's value. Further, the same behaviour (call __index__ if the regular dunder conversion method isn't present) should also be applied to int and complex - but these were a little harder to implement.

I guess the question is should we bother? It seems like an esoteric corner of the language...

It's confusing that other dunder converter functions like int and str work but not float. This PR resolves this, though in a different way to these other functions.

Did you consider using the same approach as those existing ones, using MP_UNARY_OP_FLOAT?

Did you consider using the same approach as those existing ones, using MP_UNARY_OP_FLOAT?

I briefly did but saw the comment here about if forcing a bytecode update:

I presume this was is more efficient? I haven't followed that code path enough to know how it works yet.

That being said I guess "not updating the bytecode version" isn't a great excuse for taking shortcuts though, consistency with existing code is important...

update: geez I am blind sometimes... that's what I get for rushing I guess. Only a few lines below that comment I linked above is the follow up comment // Following ops cannot appear in the bytecode which include int etc, so yeah it's really not an issue to do this properly. I'll look into it.

Codecov Report

Merging #8857 (c3bc82c) into master (6519b1b) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #8857   +/-   ##
=======================================
  Coverage   98.31%   98.31%           
=======================================
  Files         157      157           
  Lines       20349    20365   +16     
=======================================
+ Hits        20006    20022   +16     
  Misses        343      343           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6519b1b...c3bc82c. Read the comment docs.

Looking closer at the existing __int__ UNARY handling:

// Qstrs for special methods are guaranteed to have a small value, so we use byte
// type to represent them.
const byte mp_unary_op_method_name[MP_UNARY_OP_NUM_RUNTIME] = {
    [MP_UNARY_OP_BOOL] = MP_QSTR___bool__,
    [MP_UNARY_OP_LEN] = MP_QSTR___len__,
    [MP_UNARY_OP_HASH] = MP_QSTR___hash__,
    [MP_UNARY_OP_INT] = MP_QSTR___int__,

Is the point of all these functions that they return a small int / non-gc object? As such float and complex wouldn't fit here as they return larger objects?

Is the point of all these functions that they return a small int / non-gc object?

No. It's just that the mp_unary_op_method_name array has byte-size elements, not qstr-size elements.

@dpgeorge new approach added in #8899

Superseded by #8899.