Mark Dickinson <dicki...@gmail.com> added the comment: Shrug. That doesn't really bother me. x**y%z and pow(x, y, z) aren't going to match anyway, as soon as x**y has to be rounded.
What would bother me more is the idea of having, with precision 4: pow(3, 22, 12347) -> nan pow(3, 23, 12347) -> 7820 pow(3, 24, 12347) -> nan pow(3, 25, 12347) -> 8645 pow(3, 26, 12347) -> 1241 etc. (or a similar phenomenon with the 1st argument varying and 2nd and 3rd arguments fixed). Or something that called pow(x, 3, 100003) with precision 5, and worked for all but 3 possible values of x. That sort of thing is the cause of hidden bugs. It's all academic really; no-one's going to use Decimal's 3-argument pow. I'm not really sure why it's supported at all. Come to that, I don't really understand why Python's 3-argument pow belongs in the core interpreter (as opposed to somewhere in the standard library). If it hadn't been there, and if __pow__ didn't accept a third argument, I suspect no-one would have tried to implement 3-argument pow for Decimal. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7049> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
