Mark Dickinson <dicki...@gmail.com> added the comment: Well, the real problem is that powmod doesn't really belong in the decimal module at all. It's not a natural primitive arithmetic operation; it's certainly not naturally a floating-point operation; nothing like this appears in any floating-point standard that I'm aware of; and its (few) use cases are very different from typical decimal use cases. I'd like to bet that it currently has precisely 0 users. Trying to shoehorn powmod into the decimal module and make its semantics fit with the rest of the module seems a little pointless to me.
Really, what's the point of making any sort of attempt to preserve exponents in 3-argument pow? Having the result exponent be 0 is clean, simple to understand, simple to implement (which your proposal is not), and matches the use-cases. The restriction on the modulus also matches the use-cases: typically, the modulus m is fixed, and you won't have any expectations about the output of powmod(a, b, m) except that you'll know the result is an integer in the range 0 <= x < m. Having powmod reject m's for which only part of this range is representable avoids hard-to-find bugs where powmod(a, b, m) works for most values of a but then unexpectedly fails for some particular value of a because the result is just larger than can be represented. ---------- _______________________________________ 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
