itertools.count() as built-in

[jantod]

Is there any chance of itertools.count() ever becoming one of the
built-in functions? It's a wonderful little function and I find myself
importing it in every module I write.

-Janto

 

[John Machin]

Is there any chance of itertools.count() ever becoming one of the
built-in functions? It's a wonderful little function and I find myself
importing it in every module I write.

Every module?? Do you use any/many other itertools functions? Care to
give us a sample of your typical usage of itertools.count?

Cheers,
John

 

[jantod]

I have a project of around 6000 lines where I used count() 20 times. It
has 14 modules, 10 of which I needed an explicit import.

Many of the usages are of the form:

for item, n in zip(items, count(N)):
dostuff

Around half of these are due to using pylab.subplot(x,y.n), which
requires values for n>=1. So I want N=1. The enumerate builtin starts
from 0.
I also write out textual reports that start with n=1.

I also have things like
for n, component, rotations in zip(count(),
sorted(tools.component_files().keys()), all_symbol_rotations)
where the enumerate version just looks even more confusing and easy to
mess up
for n, component, rotations in
enumerate(sorted(tools.component_files().keys()), all_symbol_rotations)

Some more examples follow. Note that I find it more natural to specify
the count last as it's usually less important than the other values.
This is different from the order given by enumerate, so I'm more
inclined to use count().

mutated_symbols_and_names = zip(mutated_symbols, (("<%s mutation %s>" %
(component, m)) for m in count()))
edge_weight=dict(zip(Intersection.types, count(1)))
for (component, filename), n in zip(components, count()):
for (component, filename), component_count in
zip(tools.component_files().items(), count()):

 

[jantod]

Oh and I use repeat, chain and cycle quite a bit. But I don't mind
importing them as they are usually limited to one module.

 

[Alex Martelli]

I have a project of around 6000 lines where I used count() 20 times. It
has 14 modules, 10 of which I needed an explicit import.

Many of the usages are of the form:

for item, n in zip(items, count(N)):
dostuff

Around half of these are due to using pylab.subplot(x,y.n), which
requires values for n>=1. So I want N=1. The enumerate builtin starts
from 0.

Hmmm, makes me wonder if enumerate should grow optional arguments for
starting and stepping... I've found myself in similar situations, using
"x*i+y" on the i returned by enumerate, or zipping an xrange instead...


Alex

 

[John Machin]

I have a project of around 6000 lines where I used count() 20 times. It
has 14 modules, 10 of which I needed an explicit import.

Many of the usages are of the form:

for item, n in zip(items, count(N)):
dostuff

Around half of these are due to using pylab.subplot(x,y.n), which
requires values for n>=1. So I want N=1. The enumerate builtin starts
from 0.

Call me a Luddite if you will, but I'd suggest that instead of
for item, n in zip(items, count(N)):
dostuff(item, n)
you try
(1)
for n, item in enumerate(items):
dostuff(item, n+N)
or (2)
n = N-1
for item in items:
n += 1
dostuff(item, n)

I also write out textual reports that start with n=1.

I also have things like
for n, component, rotations in zip(count(),
sorted(tools.component_files().keys()), all_symbol_rotations)
where the enumerate version just looks even more confusing and easy to
mess up
for n, component, rotations in
enumerate(sorted(tools.component_files().keys()), all_symbol_rotations)

As enumerate takes only 1 argument, I presume that is the messed-up version.

Yes, the correct version is a pain:
for n, (component, rotations) in enumerate(zip(yadda1, yadda2)):

Perhaps you could use something like this:
.... for x, guff in enumerate(zip(*args)):
.... yield guff + (x + N,)
....

>>> list(zipwithcount(666, 'abc', 'xyz')) [('a', 'x', 666), ('b', 'y', 667), ('c', 'z', 668)]
>>>

Cheers,
John

 

[jantod]

Oops. The messed-up version wasn't supposed to be messed-up. Two
mistakes on one line. Which kinda proves my point

I'd much rather use the count version than (1) or (2). (1) has the
problem of having "incorrect" values the rest of the time in the loop
and (2) is going to an extreme just to avoid an import of count.

Your zipwithcount doesn't look as obvious as
for n, a, b in zip(count(), A, B)
but is still easier to read than
for n, (a, b) in enumerate(zip(A, B))

-Janto

 

[jantod]

Zipping an xrange? I'm having trouble visualizing how you do that to
avoid x*i+y.

-Janto

 

[Duncan Smith]

Zipping an xrange? I'm having trouble visualizing how you do that to
avoid x*i+y.

-Janto

Something like,

lis = ['a', 'b', 'c', 'd']
y = 3
i = 7
for n, item in zip(xrange(y, len(lis)*i+y, i), lis):

print n, item


3 a
10 b
17 c
24 d
Duncan

 

[Alex Martelli]

Zipping an xrange? I'm having trouble visualizing how you do that to
avoid x*i+y.

-Janto

Something like,

lis = ['a', 'b', 'c', 'd']
y = 3
i = 7
for n, item in zip(xrange(y, len(lis)*i+y, i), lis):

print n, item

Actually I tend to use sys.maxint as the xrange's middle arg, but, yes,
this IS the general idea!-)


Alex

 

[Raymond Hettinger]

Is there any chance of itertools.count() ever becoming one of the
built-in functions?

That's unlikely. The goal is to have fewer builtins rather than more.
Utility and frequency are not the only considerations; otherwise
glob.glob, sys.stderr, print.pprint, copy.copy, and many others would
also be candidates.

It's a wonderful little function and I find myself
importing it in every module I write.

I'm glad you find it so useful.


Raymond