Here's another sweet and short PEP. What do folks think? Is xrange()'s complexity really worth having? --Guido van Rossum (home page: http://www.python.org/~guido/) PEP: 260 Title: Simplify xrange() Version: $Revision: 1.1 $ Author: guido@python.org (Guido van Rossum) Status: Draft Type: Standards Track Python-Version: 2.2 Created: 26-Jun-2001 Post-History: 26-Jun-2001 Abstract This PEP proposes to strip the xrange() object from some rarely used behavior like x[i:j] and x*n. Problem The xrange() function has one idiomatic use: for i in xrange(...): ... However, the xrange() object has a bunch of rarely used behaviors that attempt to make it more sequence-like. These are so rarely used that historically they have has serious bugs (e.g. off-by-one errors) that went undetected for several releases. I claim that it's better to drop these unused features. This will simplify the implementation, testing, and documentation, and reduce maintenance and code size. Proposed Solution I propose to strip the xrange() object to the bare minimum. The only retained sequence behaviors are x[i], len(x), and repr(x). In particular, these behaviors will be dropped: x[i:j] (slicing) x*n, n*x (sequence-repeat) cmp(x1, x2) (comparisons) i in x (containment test) x.tolist() method x.start, x.stop, x.step attributes By implementing a custom iterator type, we could speed up the common use, but this is optional (the default sequence iterator does just fine). I expect it will take at most an hour to rip it all out; another hour to reduce the test suite and documentation. Scope This PEP only affects the xrange() built-in function. Risks Somebody's code could be relying on the extended code, and this code would break. However, given that historically bugs in the extended code have gone undetected for so long, it's unlikely that much code is affected. Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: