itertools.ilen?

[Terry Reedy]

"Jeremy Fincher" <fincher.*@osu.edu> wrote in message
news:bgt50s$7no$1 at news.cis.ohio-state.edu...
> Terry Reedy wrote:
> > An iterator is a function/method that traverses (or possibly
> > generates) a seqeuence.  The sequence has a length (actual or
> > potential) but the iterator does not.
>
> Even some sequences don't have a length;

I was allowing for 'infinity'

>  Or any class with a somehow non-terminating __len__.

If the instance wraps or somehow comprises a finite collection, so
that it conceptually has a len, then such a __len__ function would be
a bug.

>> Alternative: initialize six counters to 0.  Scan list once and
update
>> appropriate counter.

>Yes, that works in this particular case, and is probably a superior
solution.

I though the OP should get something practical from the discussion.

[..]
> That's why I don't think such a change should be made to len();
*all*
> iterators are destructive

Iterating over tuple, list, or dict is not destructive at all as I
meant the word.  Ditto for counting the output of a terminating
generator whose function and args are still available to reproduce the
generator.  I regard (irange, n) as a condensed representation of the
sequence generated.   The iterator 'self  destructs' in usage, so that
len(iterator) would work only once, but the process may or may not
prevent re-iteration.

For many generators, it is possible to calculate the total length from
the arguments (one of which may actually be the length), and to do so
much faster than counting.  When the length is not trivial, adding the
formula to the doc string could be helpful.  But if there is no such
formula (such as with the filter examples) then we are back to
counting one by one.

> and len() silently destroying them doesn't seem
> generally useful enough for the potential for mistake.

Which is why I 'tossed out an idea' rather than 'made a proposal' ;-)

One conceptual problem is that each .next() call reduces the remaining
length of the underlying sequence.  The OP's count function would only
measure this shrinking length rather than the starting length.

Terry J. Reedy






>
> > In the meanwhile, is this really a bottleneck for you? or merely
the
> > 'pity' of a program running in 1 sec when 0.1 is possible?