Merged revisions 61413-61414 via svnmerge from

svn+ssh://pythondev@svn.python.org/python/trunk

........
  r61413 | raymond.hettinger | 2008-03-16 06:20:42 +0100 (Sun, 16 Mar 2008) | 1 line

  Update docs to reflect removal of Exact/Inexact
........
  r61414 | georg.brandl | 2008-03-16 09:00:19 +0100 (Sun, 16 Mar 2008) | 2 lines

  #2299: typos in newtypes.rst.
........
This commit is contained in:
Christian Heimes 2008-03-16 17:29:44 +00:00
parent 0c1f7c0c8a
commit f75b290300
2 changed files with 7 additions and 29 deletions

View File

@ -428,7 +428,7 @@ reference counts. When don't we have to do this?
* when decrementing a reference count in a :attr:`tp_dealloc` handler when
garbage-collections is not supported [#]_
We want to want to expose our instance variables as attributes. There are a
We want to expose our instance variables as attributes. There are a
number of ways to do that. The simplest way is to define member definitions::
static PyMemberDef Noddy_members[] = {
@ -616,7 +616,7 @@ and register it in the :attr:`tp_getset` slot::
Noddy_getseters, /* tp_getset */
to register out attribute getters and setters.
to register our attribute getters and setters.
The last item in a :ctype:`PyGetSetDef` structure is the closure mentioned
above. In this case, we aren't using the closure, so we just pass *NULL*.
@ -1538,7 +1538,7 @@ might be something like the following::
less careful about decrementing their reference counts, however, we accept
instances of string subclasses. Even though deallocating normal strings won't
call back into our objects, we can't guarantee that deallocating an instance of
a string subclass won't. call back into out objects.
a string subclass won't call back into our objects.
.. [#] Even in the third version, we aren't guaranteed to avoid cycles. Instances of
string subclasses are allowed and string subclasses could allow cycles even if

View File

@ -6,9 +6,8 @@
The :mod:`numbers` module (:pep:`3141`) defines a hierarchy of numeric abstract
base classes which progressively define more operations. These concepts also
provide a way to distinguish exact from inexact types. None of the types defined
in this module can be instantiated.
base classes which progressively define more operations. None of the types
defined in this module can be instantiated.
.. class:: Number
@ -17,27 +16,6 @@ in this module can be instantiated.
*x* is a number, without caring what kind, use ``isinstance(x, Number)``.
Exact and inexact operations
----------------------------
.. class:: Exact
Subclasses of this type have exact operations.
As long as the result of a homogenous operation is of the same type, you can
assume that it was computed exactly, and there are no round-off errors. Laws
like commutativity and associativity hold.
.. class:: Inexact
Subclasses of this type have inexact operations.
Given X, an instance of :class:`Inexact`, it is possible that ``(X + -X) + 3
== 3``, but ``X + (-X + 3) == 0``. The exact form this error takes will vary
by type, but it's generally unsafe to compare this type for equality.
The numeric tower
-----------------
@ -77,7 +55,7 @@ The numeric tower
.. class:: Rational
Subtypes both :class:`Real` and :class:`Exact`, and adds
Subtypes :class:`Real` and adds
:attr:`Rational.numerator` and :attr:`Rational.denominator` properties, which
should be in lowest terms. With these, it provides a default for
:func:`float`.
@ -237,4 +215,4 @@ forward and reverse instances of any given operator. For example,
__add__, __radd__ = _operator_fallbacks(_add, operator.add)
# ...
# ...