Recap: PEP 276 Simple Iterator for ints

James_Althoff at James_Althoff at
Fri Nov 16 20:55:12 CET 2001

William Tanksley wrote:
>I've lost track of why we're arguing about this.  Why should we
>make any change here?  What are we fixing?

The discussion surrounding PEP 276, "Simple Iterator for ints", has
wandered off into several interesting areas.  As PEP 276 notes, there
appears to be interest in the Python community for inventing new syntax or
other mechanisms that makes it easier and more natural to specify a list of
numbers (for clarity of indexed-for-loop-based algorithms and other
scenarios).  The recent discussions around PEP 276 suggests that some
people like the idea of a Haskell-esque syntax whereby one specifies a list
of numbers using a closed-interval notation that includes a starting
number, a secondary number that helps to establish the step size, an
ellipsis-style notation, and an ending number (or variants on the above).
For example.

    for i in  [1, 2 .. 10]:

Another camp feels that the closed-interval notion is inconsistent with
other interval-oriented notations in Python and is inconvenient for the
common case of indexing sequences whereby the established convention is to
use a half-open interval that starts at 0 and ends (inclusively) at
len(sequence)-1.  Some in this camp favor the use of Python's slicing
syntax in conjunction with some existing object (the types.IntType class
object, or some specially created object, etc.) so that a list of integers
could be creating using, for example,

    for i in int[0:10:2]:

Others suggest using a generalization of the first mechanism (new
Haskell-esque syntax) that allows one to specify open versus closed
intervals using some syntactic means such as "]" for a closed (on one side)
interval and ")" for open, as in for example:

    for i in  [1, 2 .. 10):

Mixed in with this are differing viewpoints on whether the syntax should
use double dots, triple dots, no dots, fewer commas, more commas, colons,
square brackets, paren.s, etc.

Mixed in to some extent also are ambiguities about whether such constructs
return lists -- some of the proposed examples lend themselves to the
expectation that a list is constructed -- or iterators, which are better
when such lists are used in the context of a for-loop -- which is much of
the time.

The are enough variations and issues that most seem to agree that one or
more PEPs are needed to more fully specify one or more of the given

Getting back, then, to PEP 276 ...

PEP 276 does not attempt to solve the above problem of creating a new,
general-purpose mechanism for writing out a list of numbers using some
literal syntax.  PEP 276, instead, suggests a way of using iterators to
simplify the common case of using a for-loop to access items in a structure
when it is the case that those items need to be accessed by an index or
(multiple indices as in the example below).

The real-life example (modified slightly here) from PEP 276 is a two
dimensional table structure whereby cells can be accessed via a combination
of a row index and a column index and by *no* other mechanism (this is an
important point).

In current Python one might write:

    for i in xrange(table.getRowCount()):
        for j in xrange(table.getColumnCount()):
            print table.getValueAt(i,j)

Some posters seem to agree that the need to use xrange (or range) in this
(and other similar situations) is less than ideal, at best.

The mechanism of PEP 276 -- which requires no new syntax, is
straightforward to implement, and (the author alleges) is consistent with
recent iterator-oriented changes to dictionaries, strings, lists, and
tuples, -- would allow the example above to be written simply as:

    for i in table.getRowCount():
        for j in table.getColumnCount():
            print table.getValueAt(i,j)

While there is certainly merit and potential benefit in trying to invent a
new, general purpose mechanism for specifying lists of numbers, it should
be noted that for the problem that PEP 276 addresses, the various proposals
above yield things like:

    for i in [0, 1 .. table.getRowCount()-1]:
        for j in [0, 1 .. table.getColumnCount()-1]:
            print table.getValueAt(i,j)

    for i in int[0:table.getRowCount()]:
        for j in int[0:table.getColumnCount()]:
            print table.getValueAt(i,j)

    for i in integers[0:table.getRowCount()]:
        for j in integers[0:table.getRowCount()]:
            print table.getValueAt(i,j)

(Acknowledging that not every proposed variation is shown here nor various
proposed shortcuts for various proposals).

While acknowledging that several of these might read somewhat better than
xrange/range in the scenario above, it is not universally apparent that
they are a vast improvement (in this context).  And for each such proposal,
there is the issue as to whether the proposed new form returns an
actualized list or an iterator and how well suited the given choice might
be in various usage scenarios (given that you have to pick one or the
other: actualized list or iterator).

Nonetheless, as stated several times before, PEP 276 does not preclude the
adoption of a new mechanism for specifying lists of numbers similar to any
of the above proposals -- it doesn't have to be an "either or" choice.  It
simply provides a convenient way to access indexed structures in a


More information about the Python-list mailing list