Reject PEP 3128 (BList).

pep-0000.txt

@@ -121,7 +121,6 @@ Index by Category
  S  3118  Revising the buffer protocol                 Oliphant, Banks
  S  3119  Introducing Abstract Base Classes            GvR, Talin
  S  3124  Overloading, Generic Functions, Interfaces   Eby
- S  3128  BList: A Faster List-like Type               Stutzbach
  S  3131  Supporting Non-ASCII Identifiers             von Löwis
  S  3132  Extended Iterable Unpacking                  Brandl
  S  3141  A Type Hierarchy for Numbers                 Yasskin
@@ -268,6 +267,7 @@ Index by Category
  SR 3122  Delineation of the main module               Cannon
  SR 3125  Remove Backslash Continuation                Jewett
  SR 3126  Remove Implicit String Concatenation         Jewett
+ SR 3128  BList: A Faster List-like Type               Stutzbach
  SR 3130  Access to Current Module/Class/Function      Jewett
 
 
@@ -497,7 +497,7 @@ Numerical Index
  SR 3125  Remove Backslash Continuation                Jewett
  SR 3126  Remove Implicit String Concatenation         Jewett
  SA 3127  Integer Literal Support and Syntax           Maupin
- S  3128  BList: A Faster List-like Type               Stutzbach
+ SR 3128  BList: A Faster List-like Type               Stutzbach
  SA 3129  Class Decorators                             Winter
  SR 3130  Access to Current Module/Class/Function      Jewett
  S  3131  Supporting Non-ASCII Identifiers             von Löwis

pep-3128.txt

@@ -4,7 +4,7 @@ Version: $Revision$
 Last-Modified: $Date$
 Author: Daniel Stutzbach <daniel@stutzbachenterprises.com>
 Discussions-To: Python 3000 List <python-3000@python.org>
-Status: Draft
+Status: Rejected
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 30-Apr-2007
@@ -12,6 +12,33 @@ Python-Version: 2.6 and/or 3.0
 Post-History: 30-Apr-2007
 
 
+Rejection Notice
+================
+
+Rejectd based on Raymond Hettinger's sage advice [4]_:
+
+    After looking at the source, I think this has almost zero chance
+    for replacing list().  There is too much value in a simple C API,
+    low space overhead for small lists, good performance is common use
+    cases, and having performance that is easily understood.  The
+    BList implementation lacks these virtues and trades-off a little
+    performance is common cases for much better performance in
+    uncommon cases.  As a Py3.0 PEP, I think it can be rejected.
+
+    Depending on its success as a third-party module, it still has a
+    chance for inclusion in the collections module.  The essential
+    criteria for that is whether it is a superior choice for some
+    real-world use cases.  I've scanned my own code and found no instances
+    where BList would have been preferable to a regular list.  However,
+    that scan has a selection bias because it doesn't reflect what I would
+    have written had BList been available.  So, after a few months, I
+    intend to poll comp.lang.python for BList success stories.  If they
+    exist, then I have no problem with inclusion in the collections
+    module.  After all, its learning curve is near zero -- the only cost
+    is the clutter factor stemming from indecision about the most
+    appropriate data structure for a given task.
+
+
 Abstract
 ========
 
@@ -339,6 +366,9 @@ References
 .. [3] Discussion on python-3000 starting at post:
    http://mail.python.org/pipermail/python-3000/2007-April/006757.html
 
+.. [4] Raymond Hettinger's feedback on python-3000:
+   http://mail.python.org/pipermail/python-3000/2007-May/007491.html
+
 Copyright
 =========