Mark Dickinson <dicki...@gmail.com> added the comment: I believe that this was a deliberate design decision, though now that I look it seems it's not well documented. That should probably be fixed, so I see this as a documentation issue.
More details: The specification on which the decimal module is based requires that there be a 'remainder' operation with the semantics of Decimal's '%' operation (i.e., the result of x % y has the sign of x). However, the specification doesn't say anything about how the prescribed operations should map to language constructs. So the choice was between (1) leaving '%' for Decimal objects unimplemented, and providing a separate 'remainder' method, or (2) mapping '%' to Decimal's remainder operation, and accepting the slight mismatch between the '%' semantics for float and Decimal. Perhaps the wrong choice was made. But it's there now, and to me it's not so obviously wrong that it's worth the upheaval of deprecating '%' for Decimal objects. Of course there's a third choice, which is to implement the float % semantics for the Decimal type; however, this is outside the scope of the specification---none of the specified operations matches this behaviour, and I'd oppose the addition of such an operation to the Decimal module. There's a strong sense in which Decimal's % is a more natural operation for floating-point types than float's %. (For one thing, it's exact in many circumstances, while float's % suffers from surprising results with negative operands.) Reclassifying as a documentation issue. ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12005> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
