count items in generator

[Cameron Laird]

In article <1hfc2sb.8hxfcv13c5v6nN%aleax at mac.com>,
Alex Martelli <aleax at mac.com> wrote:
			.
			.
			.
>I'd be a bit worried about having len(x) change x's state into an
>unusable one. Yes, it happens in other cases (if y in x:), but adding
>more such problematic cases doesn't seem advisable to me anyway -- I'd
>evaluate this proposal as a -0, even taking into account the potential
>optimizations to be garnered by having some iterables expose __len__
>(e.g., a genexp such as (f(x) fox x in foo), without an if-clause, might
>be optimized to delegate __len__ to foo -- again, there may be semantic
>alterations lurking that make this optimization a bit iffy).
>
>
>Alex

Quite so.  My proposal isn't at all serious; I'm doing this largely
for practice in thinking about functionalism and its complement in
Python.  However, maybe I should take this one step farther:  while
I think your caution about "attractive nuisance" is perfect, what is
the precise nuisance here?  Is there ever a time when a developer
would be tempted to evaluate len() on an iterable even though there's
another approach that does NOT impact the iterable's state?  On the
other hand, maybe all we're doing is observing that expanding the
domain of len() means we give up guarantees on its finiteness, and
that's simply not worth doing.