[Python-3000] Builtin iterator type

Fredrik Lundh fredrik at pythonware.com
Wed Nov 15 10:12:28 CET 2006


George Sakkis wrote:

> 1) why having a "generic operation" len() that ends up looking for an
> ugly special *method* called  __len__() makes sense, while calling
> directly a method len() doesn't

for the very reason Mike explained: keeping implementation interfaces 
separate from public interfaces has allowed Python to avoid a certain 
category of design fragmentation that other languages suffer from.

> 2) if "generic operations" are such a cool idea, why there aren't more
> of them, such as count() or index() (the former for any container
> type, the latter for sequence types).

count() isn't that common, really (and can be written as sum(1 for item 
in iterable if condition) if you really want), and things like "in" and 
"any" and "enumerate" are already built-ins.

> I don't think that defending a decision by pointing out a different
 > bad decision in another language (Java's inconsistency between
 > string.length and > list.length()) > is a particularly compelling
 > argument

see above.

> The ending sentences though are more convincing: "...but it's a part
 > of Python, and it's too late to make such fundamental changes now.
 > The functions have to remain to avoid massive code breakage". That
 > I can buy (at least for 2.x).

yeah, it's clear that most of your argumentation is based on a rather 
common "I haven't thought this through very deeply, but I'm sure I'm 
smarter than those guys so that won't stop me" approach.  trust me, the 
design of Python is a *lot* more carefully put together than you appear 
to think.

</F>



More information about the Python-3000 mailing list