# enumerate improvement proposal

James Stroud jstroud at mbi.ucla.edu
Sun Oct 29 12:32:47 CET 2006

```I think that it would be handy for enumerate to behave as such:

def enumerate(itrbl, start=0, step=1):
i = start
for it in itrbl:
yield (i, it)
i += step

This allows much more flexibility than in the current enumerate,
tightens up code in many cases, and seems that it would break no
existing code. Yes, I have needed this behavior with enumerate, like
tonight and the current example. I put the "step" parameter in for
conceptual symmetry with slicing.

Here is a case use (or is it use case?):

# with the proposed enumerate
import operator
def in_interval(test, bounds, first=1, reverse=False):
op = operator.gt if reverse else operator.lt   # python 2.5
bounds = sorted(bounds, reverse=reverse)
for i, bound in enumerate(bounds, first):
if op(test, bound):
return i
return i + 1

# with the existing enumerate
import operator
def in_interval(test, bounds, first=1, reverse=False):
op = operator.gt if reverse else operator.lt   # python 2.5
bounds = sorted(bounds, reverse=reverse)
for i, bound in enumerate(bounds):
if op(test, bound):
return i + first
return i + first + 1

py> # eg
...
py> in_interval(8, bounds)
2
py> in_interval(1, bounds)
1
py> in_interval(1, bounds, reverse=True)
5
py> in_interval(8, bounds, reverse=True)
4
py> in_interval(20, bounds, reverse=True)
2

Of course, I haven't used step here. Even in this trivial example the
proposed enumerate cleans the code and logic, eliminating a couple of
plus signs. For this real-world example, the practical requirement for
reversing the bins obfuscates somewhat the de-obfuscation provided by
the proposed enumerate. But I think that it might be obvious that the
proposed enumerate could help significantly in cases a bit more
complicated than this one.

Any thoughts?

James

```