Steven D'Aprano: >Extending len() to support iterables sounds like a good idea, except that it's >not.<
Python language lately has shifted toward more and more usage of lazy iterables (see range lazy by default, etc). So they are now quite common. So extending len() to make it act like leniter() too is a way to adapt a basic Python construct to the changes of the other parts of the language. In languages like Haskell you can count how many items a lazy sequence has. But those sequences are generally immutable, so they can be accessed many times, so len(iterable) doesn't exhaust them like in Python. So in Python it's less useful. This is a common situation where I can only care of the len of the g group: [leniter(g) for h,g in groupby(iterable)] There are other situations where I may be interested only in how many items there are: leniter(ifilter(predicate, iterable)) leniter(el for el in iterable if predicate(el)) For my usage I have written a version of the itertools module in D (a lot of work, but the result is quite useful and flexible, even if I miss the generator/iterator syntax a lot), and later I have written a len() able to count the length of lazy iterables too (if the given variable has a length attribute/property then it returns that value), and I have found that it's useful often enough (almost as the string.xsplit()). But in Python there is less need for a len() that counts lazy iterables too because you can use the following syntax that isn't bad (and isn't available in D): [sum(1 for x in g) for h,g in groupby(iterable)] sum(1 for x in ifilter(predicate, iterable)) sum(1 for el in iterable if predicate(el)) So you and Python designers may choose to not extend the semantics of len() for various good reasons, but you will have a hard time convincing me it's a useless capability :-) Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list