Guido van Rossum 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.
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.
__________________________________
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
