itertools.count() as built-in
jan...@gmail.com
built-in functions? It's a wonderful little function and I find myself
importing it in every module I write.
-Janto
John Machin
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
jan...@gmail.com
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()):
jan...@gmail.com
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:
>>> def zipwithcount(N, *args):
... 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
jan...@gmail.com
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
jan...@gmail.com
avoid x*i+y.
-Janto
Duncan Smith
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
> jan...@gmail.com wrote:
> > 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