Do note that this discussion is only about Python 3. Under the view that it was a (minor, but real) design error to /try/ extending Python's integer mod definition to floats, if __mod__, and __divmod__ and __floordiv__ go away for binary floats in P3K they should certainly go away for decimal floats in P3K too. And that's about syntax, not functionality: the IBM spec's "remainder" and "remainder-near" still need to be there, it's "just" that a user would have to get at "remainder" in a more long-winded way (analogous to
[Facundo Batista]
We'll have to deprecate that functionality, with proper warnings (take not I'm not following the thread that discuss the migration path to 3k).
And we'll have to add the method "remainder" to decimal objects (right now we have only "remainder_near" in decimal objects, and both "remainder" and "remainder_near" in context).
Whoa. This needs more discussion with respect to the decimal module. I'm not ready to throw-out operator access to the methods provided by the spec. Also, I do not want the Py2.x decimal module releases to be complexified and slowed-down by Py3.0 deprecation warnings. The module is already slow and has ease-of-use issues. Raymond
... [Facundo]
We'll have to deprecate that functionality, with proper warnings (take not I'm not following the thread that discuss the migration path to 3k).
And we'll have to add the method "remainder" to decimal objects (right now we have only "remainder_near" in decimal objects, and both "remainder" and "remainder_near" in context).
[Raymond]
Whoa. This needs more discussion with respect to the decimal module. I'm not ready to throw-out operator access to the methods provided by the spec.
decimal's __floordiv__ and __divmod__ have nothing to do with the spec. They were Python-specific extensions apparently added to try to fit in better with Python's entirely different (than either of decimal's) definition of modular reduction. In that respect they succeeded by being jarringly perverse: decimal's __floordiv__(a, b) does not return the floor of a/b, it returns a/b truncated toward 0:
-1 // 10 -1 Decimal(-1) // Decimal(10) Decimal("-0")
Even you might agree that's an odd thing for a function named "floor div" to do ;-) I say that's not useful. The only method here that does have something to do with the spec is decimal's __mod__, an implementation of the spec's "remainder" operation. Guido agreed last May to take away the "%" infix spelling of mod for binary floats, and I can't think of a reason for why decimal floats should be immune.
Also, I do not want the Py2.x decimal module releases to be complexified and slowed-down by Py3.0 deprecation warnings. The module is already slow and has ease-of-use issues.
We're not talking about the usual arithmetic operations here, just "%". The functionality wouldn't go away, just the infix 1-character spelling. Note that the implementation of "remainder" is extraordinarily expensive, just as the implementation of fmod for binary floats is extraordinarily expensive: it's not just the precision at work, but also the difference in exponents. + - * / don't have the latter factor to contend with (hence "extraordinarily"). Couple this with that floating mod of any kind is almost surely rarely used, and worry about the overhead of a method or function spelling seems a waste of tears. Irony: I've used decimal's remainder_near in real life, which has no operator spelling. I haven't used decimal's `remainder` except to give examples in this thread :-)
participants (2)
-
python＠rcn.com -
Tim Peters