Merged revisions 61413-61414 via svnmerge from

tiran · tiran · commit f75b29030015 · 2008-03-16T17:29:44.000Z
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. ........
diff --git a/Doc/extending/newtypes.rst b/Doc/extending/newtypes.rst
@@ -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
diff --git a/Doc/library/numbers.rst b/Doc/library/numbers.rst
@@ -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)
 
-    # ...
+    # ...
