On 9 August 2010 18:16, Alexandru Moșoi wrote:

1) sum(1 for e in iterator) 2) len(list(iterator))

First solution is slow, the second solution uses O(N) extra memory.

I propose the addition of a new function ilen() which is functionally equivalent to:

def ilen(iterator):  return sum(1 for e in iterator)

You say that this solution "is slow" and then you propose it? I'm confused. Besides which, as you define it, it exhausts the iterator, which makes it useless. It may be useful for an *iterable*, but most of them support len in any case.

This function should be different from len() because it's time complexity is O(N) (most people assume that len() takes O(1)) and it consumes the iterator.

Precisely. So how is it useful? If you could show some real code that uses your ilen function, that would help clarify. But it still won't explain why the function should be built in rather than just defined by your code where it's needed - you'll have to have some very common and compelling use cases to argue that. Paul.

Paul Moore wrote:

On 9 August 2010 18:16, Alexandru Moșoi wrote:

...

1) sum(1 for e in iterator) 2) len(list(iterator))

First solution is slow, the second solution uses O(N) extra memory.

I propose the addition of a new function ilen() which is functionally equivalent to:

def ilen(iterator): return sum(1 for e in iterator)

You say that this solution "is slow" and then you propose it? I'm confused.

That's just to describe its behaviour. An actual implementation wouldn't necessarily do it that way.

Besides which, as you define it, it exhausts the iterator, which makes it useless. It may be useful for an *iterable*, but most of them support len in any case.

...

This function should be different from len() because it's time complexity is O(N) (most people assume that len() takes O(1)) and it consumes the iterator.

Precisely. So how is it useful?

If you could show some real code that uses your ilen function, that would help clarify. But it still won't explain why the function should be built in rather than just defined by your code where it's needed - you'll have to have some very common and compelling use cases to argue that.

I agree.

On Tue, Aug 10, 2010 at 7:42 AM, Ivan Pozdeev wrote:

...

Hello,

...

Sometimes it's useful to get the number of elements yield by an iterator. For example (if ilen is the name of the function):

A generic iterator is something that inherently, by definition, has unknown and unpredictable length (think, for example, about berries you gather in a forest).

There is no guarantee two tries give the same results, there isn't even a guarantee that it's finite.

Indeed - iterating over a completely arbitrary iterator with no exit criteria is a recipe for infinite loops when someone passes in something like itertools.count or itertools.repeat.

You just can't, absolutely, by any means, know its length otherwise than by exhausting it. If you can, it's not a generic iterator but something else.

Yep, hence the existence of the __length_hint__ API as an internal optimisation when dealing with iterators that do have some idea of their length (see http://mail.python.org/pipermail/python-dev/2009-April/088108.html for discussion as to why it is undocumented). Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

2010/8/10 Scott Dial :

You are responding to his request for a specific example with a generic class of examples, which is what prompted his request for a specific example in the first place. Please give a *specific* example and be prepared to be told that you are going about it the wrong way, since, at this point, nobody has replied as having recognized this as a problem they've encountered before.

My exact need is to count the not-None elements in a list. My current solution is, as described before: sum(1 for e in iterator if not e) -- Alexandru Moșoi http://www.alexandru.mosoi.ro/

Can you all take this off-line? It is turning into programming help instead of a feature discussion. -- --Guido van Rossum (python.org/~guido)