iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Reject PEP 3128 (BList).

This commit is contained in:
Guido van Rossum 2007-05-10 23:41:53 +00:00
parent 41cc7d87e0
commit f90b4368a8
2 changed files with 33 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
pep-0000.txt
View File

@ -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

32
pep-3128.txt
View File

@ -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
=========