Raymond Hettinger added the comment: 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. ---------- assignee: jyasskin -> gvanrossum nosy: +gvanrossum __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2002> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
