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



More information about the Python-list mailing list