Title: Provide as_integer_ratio() method to Decimal
Type: enhancement Stage: patch review
Components: Extension Modules Versions: Python 3.2
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: belopolsky, mark.dickinson, rhettinger, skrah
Priority: normal Keywords: patch

Created on 2010-06-08 20:51 by belopolsky, last changed 2010-06-29 20:07 by mark.dickinson. This issue is now closed.

File name Uploaded Description Edit
issue8947.patch mark.dickinson, 2010-06-11 12:38
issue8947_2.patch mark.dickinson, 2010-06-11 12:56
Messages (9)
msg107345 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-08 20:51
Here is my use case: recently implemented timedelta * float operation starts with converting float to an int ratio.  The same algorithm can be used for decimals, but they don't support as_integer_ratio().
msg107348 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-08 21:10
This seems like a reasonable request to me;  I'd like to see a little bit of convergence between the float and Decimal APIs.

One difference between the two types that's worth noting is that the float.as_integer_ratio() method can never take a ridiculous amount of time or memory, whereas Decimal.as_integer_ratio() could:  e.g., consider Decimal('1e999999999').as_integer_ratio().  But I don't really see that as a problem.
msg107542 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-11 12:38
Here's a patch.
msg107543 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-11 12:56
Updated patch, taking into account comments from merwok and exarkun on #python-dev:

 - remove doctests for infinity and nan, replace with a sentence
   explaining what happens for such inputs.
 - replace 'snAN' with saner spelling 'snan'.
msg107622 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-12 03:24
Nice implementation.  I wonder if the /5 loop can be eliminated by noting that /5 is *2 followed by decimal shift. (Probably not without fast decimal arithmetics.)

A few documentation nits:

1. In Decimal methods there is no consistency in referring to self.  I see  "given Decimal", "the number", and "the argument" in three entries around as_integer_ratio().

2. Is there a reason that docstring is more detailed than manual entry?  I think the manual should describe exceptions.

3. Is there a reason to use different language for float.as_integer_ratio() and Decimal.as_integer_ratio()?

I know, ""A foolish consistency is the hobgoblin of little minds..." - feel free to ignore my observations.

A tiny code nit: to me it would be clearer to start with d2 = d5 = -self._exp after the "# Find d2, d5 ..." comment.  For a moment I was puzzled why you promise d2 and d5, but then process d5 only.

Also, by the time of the "if not self" check, special case has been eliminated, so you can simply check self._int == 0.
msg108600 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-25 14:35
Raymond, do you have any thoughts on this proposal?
msg108613 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-06-25 18:07
-0  I don't think we really need this (we've already got a reasonable conversion to Fraction).

In general, we should have a aversion to adding any methods to the decimal API because it is already very fat.  Adding more methods makes it harder to figure out which one is the right one to use.
msg108615 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-25 18:27

conversion to Fraction does not really help in my use case of supporting timedelta * Decimal by duck typing.  I can think of many other use cases where it will be helpful to accept either float or decimal without loss of precision.  Is there an alternative way to achieve that which does not require importing the decimal module first?
msg108944 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-29 20:07
After discussions on IRC, I'm going to close this as rejected.  Convergence of the float and Decimal APIs is a nice idea, but in this case it's not clear that it really works.  In particular, for duck typing to be sensible, int and Fraction would also have to grow an as_integer_ratio method.  And that seems a superfluous when those two types already have the same functionality in the form of .numerator and .denominator attributes.

I also agree with Raymond that we shouldn't be fattening the decimal API without good reason.

Alexander:  wouldn't conversion to Fraction solve the issue in this case?  The Fraction constructor accepts floats, Decimal instances and ints directly.
Date User Action Args
2010-06-29 20:07:25mark.dickinsonsetstatus: open -> closed
resolution: rejected
messages: + msg108944
2010-06-25 18:27:18belopolskysetmessages: + msg108615
2010-06-25 18:07:51rhettingersetmessages: + msg108613
2010-06-25 14:35:39mark.dickinsonsetnosy: + rhettinger
messages: + msg108600
2010-06-12 03:24:51belopolskysetmessages: + msg107622
2010-06-11 12:56:36mark.dickinsonsetfiles: + issue8947_2.patch

messages: + msg107543
2010-06-11 12:38:16mark.dickinsonsetfiles: + issue8947.patch
keywords: + patch
messages: + msg107542

stage: patch review
2010-06-09 15:31:30skrahsetnosy: + skrah
2010-06-08 21:18:45mark.dickinsonsetassignee: mark.dickinson
2010-06-08 21:10:29mark.dickinsonsetnosy: + mark.dickinson
messages: + msg107348
2010-06-08 20:51:06belopolskycreate