"Greg Ewing" <greg.ewing at canterbury.ac.nz> wrote in message news:44052636.9090709 at canterbury.ac.nz... > And you don't think there are many different > types of iterables? You might as well argue > that we don't need len() because it "only > applies to sequences". Since you mention it..., many people *have* asked on c.l.p why len() is a builtin function rather than a method of sequences (and other collections) (as .len, not .__len__). Some have suggested that it should be the latter. The answers justifying the status quo have been twofold. 1. Before 2.2, not all builtin sequence types had methods (str and tuple), so they could not have a .len method. (This begs the question of why not, but that is moot now.) - whereas .next came in with the universalization of methods. 2. Before the addition of list comprehensions, a function could be mapped much more easily than a method - whereas now we do have list comps and even this works >>> [i.__add__(2) for i in range(3)] [2, 3, 4] - I can imagine wanting to map len to, for instance, a list of strings more easily than I can imagine a reason to map next/.next to a list of iterators, and if I did, I am willing to use the list comp form. Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4