[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