<mattip>
If __int__(), __float__() and __complex__() are not defined then corresponding built-in functions int(), float() and complex() fall back to __index__()
<cfbolz>
mattip: is that related to 3.8?
<cfbolz>
Something changed around that
<mattip>
yes, the failures of hpy on py3.8
<cfbolz>
I think it's not fixed yet
<cfbolz>
Or maybe not in all cases
<cfbolz>
I hope to get back to 3.8 work this week :-(
<mattip>
in baseobjspace.py, there is "def int(self. w_obj): return w_obj.int(self)"
<cfbolz>
mattip: I never know what space.int is supposed to do precisely
<mattip>
well, it calls w_obj.int
<cfbolz>
Sure
<mattip>
W_Root.int() is also in that file, at line 302
<cfbolz>
But in which situations do you use it
Julian has quit [Ping timeout: 268 seconds]
<cfbolz>
mattip: ie does the int constructor use it?
<mattip>
ahh. HPy and cpyext both use it in HPyLong_AsLong or PyLong_AsLong
<cfbolz>
mattip: so we should check whether the latter in cpython will call index
<mattip>
but maybe they should be using space.newint
<cfbolz>
If yes, that's an argument for changing space.int
<mattip>
In order to have a coherent integer type class, when __index__() is defined __int__() should also be defined, and both should return the same value.