| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
| |
(See issue 3056 -- we're close to a resolution but need unittests.)
|
| |
|
|
|
|
| |
* Convert binary methods in Integral to mixin methods
* Remove three-arg __pow__ as a required method
* Make __int__ the root method instead of __long__.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
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.
|
