[Python-checkins] python/nondist/peps pep-3000.txt,1.13,1.14

[bcannon at users.sourceforge.net]

Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22604

Modified Files:
	pep-3000.txt 
Log Message:
sum()'s second argument is returned if the first argument is empty, otherwise
it is ignored.


Index: pep-3000.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-3000.txt,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -d -r1.13 -r1.14
--- pep-3000.txt	11 Mar 2005 00:56:22 -0000	1.13
+++ pep-3000.txt	15 Mar 2005 04:06:02 -0000	1.14
@@ -90,14 +90,15 @@
 * Introduce ``trunc()``, which would call the ``__trunc__()`` method on its
   argument; suggested use if for objects like float where calling ``__int__()``
   has data loss, but an integral representation is still desired [8]_
+* The second argument to ``sum()`` will returned if the first argument is
+  empty, otherwise it is ignored [10]_
 
 To be removed:
 
 * ``apply()``: use ``f(*args, **kw)`` instead [2]_
 * ``buffer()``: must die (use a bytes() type instead) [2]_
 * ``callable()``: just call the object and catch the exception [2]_
-* ``compile()``: put in ``sys`` (or perhaps in a module of its own)
-  [2]_
+* ``compile()``: put in ``sys`` (or perhaps in a module of its own) [2]_
 * ``coerce()``: no longer needed [2]_
 * ``execfile()``, ``reload()``: use ``exec()`` [2]_
 * ``input()``: use ``eval(sys.stdin.readline())`` [2]_
@@ -143,13 +144,16 @@
 .. [7] python-dev email ("Let's get rid of unbound methods")
    http://mail.python.org/pipermail/python-dev/2005-January/050625.html
 
-.. [8] python-dev email( "Fixing _PyEval_SliceIndex so that integer-like
+.. [8] python-dev email ("Fixing _PyEval_SliceIndex so that integer-like
    objects can be used")
    http://mail.python.org/pipermail/python-dev/2005-February/051674.html
 
 .. [9] Guido's blog ("The fate of reduce() in Python 3000")
    http://www.artima.com/weblogs/viewpost.jsp?thread=98196
 
+.. [10] python-dev email ("Rationale for sum()'s design?")
+   http://mail.python.org/pipermail/python-dev/2005-March/052183.html
+
 
 Copyright
 =========