Commit Graph

13 Commits

Author SHA1 Message Date
Guido van Rossum 21a45e1bea Roll back Raymond's -r64098 while we think of something better.
(See issue 3056 -- we're close to a resolution but need unittests.)
2008-06-17 17:38:02 +00:00
Raymond Hettinger caea65e465 Mini-PEP: Simplifying numbers.py
* Convert binary methods in Integral to mixin methods
* Remove three-arg __pow__ as a required method
* Make __int__ the root method instead of __long__.
2008-06-11 00:25:29 +00:00
Raymond Hettinger cd6bfab410 Zap one more use of Exact/Inexact. 2008-03-15 20:37:50 +00:00
Raymond Hettinger 6b46762974 Removed Exact/Inexact after discussion with Yasskin.
Unlike Scheme where exactness is implemented as taints, the Python
implementation associated exactness with data types.  This created
inheritance issues (making an exact subclass of floats would result
in the subclass having both an explicit Exact registration and an
inherited Inexact registration).  This was a problem for the
decimal module which was designed to span both exact and inexact
arithmetic.  There was also a question of use cases and no examples
were found where ABCs for exactness could be used to improve code.
One other issue was having separate tags for both the affirmative
and negative cases.  This is at odds with the approach taken
elsewhere in the Python (i.e. we don't have an ABC both Hashable
and Unhashable).
2008-03-15 20:02:04 +00:00
Raymond Hettinger ddb164a651 Update notes on Decimal. 2008-02-14 01:08:02 +00:00
Raymond Hettinger 116f72fa5c Bring decimal a bit closer to the spec for Reals. 2008-02-12 01:18:03 +00:00
Raymond Hettinger 19a5c29d27 Fix typo in comments 2008-02-12 00:48:20 +00:00
Raymond Hettinger 48688d8c8e Add notes on how decimal fits into the model. 2008-02-11 22:53:01 +00:00
Jeffrey Yasskin 27d339446a Oops! 2.6's Rational.__ne__ didn't work. 2008-02-08 06:45:40 +00:00
Jeffrey Yasskin b23dea6adb Added more documentation on how mixed-mode arithmetic should be implemented. I
also noticed and fixed a bug in Rational's forward operators (they were
claiming all instances of numbers.Rational instead of just the concrete types).
2008-01-31 07:44:11 +00:00
Jeffrey Yasskin d7b00334f3 Add rational.Rational as an implementation of numbers.Rational with infinite
precision. This has been discussed at http://bugs.python.org/issue1682. It's
useful primarily for teaching, but it also demonstrates how to implement a
member of the numeric tower, including fallbacks for mixed-mode arithmetic.

I expect to write a couple more patches in this area:
 * Rational.from_decimal()
 * Rational.trim/approximate() (maybe with different names)
 * Maybe remove the parentheses from Rational.__str__()
 * Maybe rename one of the Rational classes
 * Maybe make Rational('3/2') work.
2008-01-15 07:46:24 +00:00
Jeffrey Yasskin 9871d8fe22 Continue rolling back pep-3141 changes that changed behavior from 2.5. This
round included:
 * Revert round to its 2.6 behavior (half away from 0).
 * Because round, floor, and ceil always return float again, it's no
   longer necessary to have them delegate to __xxx___, so I've ripped
   that out of their implementations and the Real ABC. This also helps
   in implementing types that work in both 2.6 and 3.0: you return int
   from the __xxx__ methods, and let it get enabled by the version
   upgrade.
 * Make pow(-1, .5) raise a ValueError again.
2008-01-05 08:47:13 +00:00
Jeffrey Yasskin 2f3c16be73 Backport PEP 3141 from the py3k branch to the trunk. This includes r50877 (just
the complex_pow part), r56649, r56652, r56715, r57296, r57302, r57359, r57361,
r57372, r57738, r57739, r58017, r58039, r58040, and r59390, and new
documentation. The only significant difference is that round(x) returns a float
to preserve backward-compatibility. See http://bugs.python.org/issue1689.
2008-01-03 02:21:52 +00:00