summaryrefslogtreecommitdiffstats
path: root/Lib/numbers.py
Commit message (Collapse)AuthorAgeFilesLines
* Issue 2235: Py3k warnings are now emitted for classes that will no longer ↵Nick Coghlan2008-08-111-0/+3
| | | | inherit a__hash__ implementation from a parent class in Python 3.x. The standard library and test suite have been updated to not emit these warnings.
* Roll back Raymond's -r64098 while we think of something better.Guido van Rossum2008-06-171-17/+50
| | | | (See issue 3056 -- we're close to a resolution but need unittests.)
* Mini-PEP: Simplifying numbers.pyRaymond Hettinger2008-06-111-50/+17
| | | | | | * Convert binary methods in Integral to mixin methods * Remove three-arg __pow__ as a required method * Make __int__ the root method instead of __long__.
* Zap one more use of Exact/Inexact.Raymond Hettinger2008-03-151-1/+1
|
* Removed Exact/Inexact after discussion with Yasskin.Raymond Hettinger2008-03-151-54/+4
| | | | | | | | | | | | | | | 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).
* Update notes on Decimal.Raymond Hettinger2008-02-141-4/+5
|
* Bring decimal a bit closer to the spec for Reals.Raymond Hettinger2008-02-121-4/+1
|
* Fix typo in commentsRaymond Hettinger2008-02-121-2/+2
|
* Add notes on how decimal fits into the model.Raymond Hettinger2008-02-111-0/+29
|
* Oops! 2.6's Rational.__ne__ didn't work.Jeffrey Yasskin2008-02-081-1/+4
|
* Added more documentation on how mixed-mode arithmetic should be implemented. IJeffrey Yasskin2008-01-311-1/+7
| | | | | 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).
* Add rational.Rational as an implementation of numbers.Rational with infiniteJeffrey Yasskin2008-01-151-3/+22
| | | | | | | | | | | | | 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.
* Continue rolling back pep-3141 changes that changed behavior from 2.5. ThisJeffrey Yasskin2008-01-051-19/+0
| | | | | | | | | | | | 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.
* Backport PEP 3141 from the py3k branch to the trunk. This includes r50877 (justJeffrey Yasskin2008-01-031-0/+393
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.
generated by cgit v0.12 at 2024-11-30 07:09:46 (GMT)