> Guido, are these basically the mechanics you intended?  All calls to
> PyNumber_Int() and PyNumber_Long() attempt the usual path and if those
> would fail, it tries __trunc__ if it exists and coerces the result of
> that call back to an int or long.

Yes, that's exactly what I suggested.

> The logic looks basically correct, but I'm not sure what it buys us
> since the returned Integral has to be converted back to an int or long
> anyway.

Unless it's already an int or long. I would expect a type that wants
to play along with the ABCs defined in numbers.py will define
__trunc__ and not __int__ (since the latter isn't part of the ABC) but
it would have to be a pretty esoteric type not to return an int or
long.

> On the plus side, it does not slow down the common case where
> PyNumber_Int() and PyNumberLong() would ordinarily succeed.

Great -- so no penalty for builtin types.

> An alternative to this patch would be to have math.trunc() try to
> return __trunc__() and if it doesn't exist, fallback to __int__.  That
> avoids having arbitrary Integrals forced back into ints/longs, but it
> may not be what you guys were after.

Definitely not -- that would imply that math.trunc("42") would return
the integer 42!

> Either way will allow a user to define a __trunc__() method and have
> math.trunc() return an arbitrary Integral, not necessarily and int or
> long.

Correct, and that's as intended.

> There is also part of this patch that touches classobject.c but I'm not
> yet sure what the visible effect of that change would be or what the
> change was hoping to accomplish.

Looks like Jeffrey expained that already.