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.  

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.  On the plus side, it does not slow down the common case where 
PyNumber_Int() and PyNumberLong() would ordinarily succeed.  

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.

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.

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.