Merged revisions 73656,73658,73663,73666 via svnmerge from

birkenfeld · birkenfeld · commit 7d1e88063c62 · 2009-08-13T08:47:18.000Z
svn+ssh://svn.python.org/python/branches/py3k

........
  r73656 | mark.dickinson | 2009-06-29 00:08:40 +0200 (Mo, 29 Jun 2009) | 1 line

  Fix description of range_length_obj
........
  r73658 | raymond.hettinger | 2009-06-29 00:30:13 +0200 (Mo, 29 Jun 2009) | 1 line

  Small doc fix-ups to floatingpoint.rst.  More are forthcoming.
........
  r73663 | raymond.hettinger | 2009-06-29 01:21:38 +0200 (Mo, 29 Jun 2009) | 1 line

  Clean-up floating point tutorial.
........
  r73666 | alexandre.vassalotti | 2009-06-29 03:13:41 +0200 (Mo, 29 Jun 2009) | 2 lines

  Make b64encode raises properly a TypeError when altchars is not bytes.
........
diff --git a/Doc/tutorial/floatingpoint.rst b/Doc/tutorial/floatingpoint.rst
@@ -82,7 +82,7 @@ values share the same approximation, any one of them could be displayed
 while still preserving the invariant ``eval(repr(x)) == x``.
 
 Historically, the Python prompt and built-in :func:`repr` function would chose
-the one with 17 significant digits, ``0.10000000000000001``, Starting with
+the one with 17 significant digits, ``0.10000000000000001``.   Starting with
 Python 3.1, Python (on most systems) is now able to choose the shortest of
 these and simply display ``0.1``.
 
@@ -123,9 +123,9 @@ Also, since the 0.1 cannot get any closer to the exact value of 1/10 and
 
 Though the numbers cannot be made closer to their intended exact values,
 the :func:`round` function can be useful for post-rounding so that results
-have inexact values that are comparable to one another::
+with inexact values become comparable to one another::
 
-    >>> round(.1 + .1 + .1, 1) == round(.3, 1)
+    >>> round(.1 + .1 + .1, 10) == round(.3, 10)
     True
 
 Binary floating-point arithmetic holds many surprises like this.  The problem
@@ -137,7 +137,7 @@ As that says near the end, "there are no easy answers."  Still, don't be unduly
 wary of floating-point!  The errors in Python float operations are inherited
 from the floating-point hardware, and on most machines are on the order of no
 more than 1 part in 2\*\*53 per operation.  That's more than adequate for most
-tasks, but you do need to keep in mind that it's not decimal arithmetic, and
+tasks, but you do need to keep in mind that it's not decimal arithmetic and
 that every float operation can suffer a new rounding error.
 
 While pathological cases do exist, for most casual use of floating-point
@@ -165,7 +165,7 @@ fraction::
 
    >>> x = 3.14159
    >>> x.as_integer_ratio()
-   (3537115888337719L, 1125899906842624L)
+   (3537115888337719, 1125899906842624)
 
 Since the ratio is exact, it can be used to losslessly recreate the
 original value::
diff --git a/Lib/base64.py b/Lib/base64.py
@@ -58,8 +58,8 @@ def b64encode(s, altchars=None):
     encoded = binascii.b2a_base64(s)[:-1]
     if altchars is not None:
         if not isinstance(altchars, bytes_types):
-            altchars = TypeError("expected bytes, not %s"
-                                 % altchars.__class__.__name__)
+            raise TypeError("expected bytes, not %s"
+                            % altchars.__class__.__name__)
         assert len(altchars) == 2, repr(altchars)
         return _translate(encoded, {'+': altchars[0:1], '/': altchars[1:2]})
     return encoded
diff --git a/Objects/rangeobject.c b/Objects/rangeobject.c
@@ -126,10 +126,9 @@ range_dealloc(rangeobject *r)
     PyObject_Del(r);
 }
 
-/* Return number of items in range (lo, hi, step), when arguments are PyLong
- * objects.  Return a value < 0 if & only if the true value is too large to
- * fit in a signed long.  Arguments MUST return 1 with PyLong_Check().  Return
- * -1 when there is an error.
+/* Return number of items in range (lo, hi, step) as a PyLong object,
+ * when arguments are PyLong objects.  Arguments MUST return 1 with
+ * PyLong_Check().  Return NULL when there is an error.
  */
 static PyObject*
 range_length_obj(rangeobject *r)
