From f90b4368a8a4811b35ca9dc177f851809eaaefe9 Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Thu, 10 May 2007 23:41:53 +0000 Subject: [PATCH] Reject PEP 3128 (BList). --- pep-0000.txt | 4 ++-- pep-3128.txt | 32 +++++++++++++++++++++++++++++++- 2 files changed, 33 insertions(+), 3 deletions(-) diff --git a/pep-0000.txt b/pep-0000.txt index 9f74035b7..c9240250c 100644 --- a/pep-0000.txt +++ b/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 diff --git a/pep-3128.txt b/pep-3128.txt index 14a0042f3..f7acd4def 100644 --- a/pep-3128.txt +++ b/pep-3128.txt @@ -4,7 +4,7 @@ Version: $Revision$ Last-Modified: $Date$ Author: Daniel Stutzbach Discussions-To: Python 3000 List -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 =========