J
James Stroud
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
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