[Python-3000] Builtin iterator type

[Bob Ippolito]

On 11/15/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
> George Sakkis wrote:
>
> > Fredrik, I am not arguing for the argument's sake, I just don't get
> > it: Python requires my class to define __len__, otherwise len() fails.
> > Why not require len() as a method instead and forget about __len__ ?
>
> and have people complain about a len/__getitem__ naming inconsistency?
> (cf. the __iter__/next vs. __iter__/__next__ discussions.)
>
> > Does len() (the function) do anything smarter behind the scenes than
> > just passing the ball to __len__ ?
>
> yes.  len() can use alternative approaches to determine the length for
> objects implemented in the host language.  this is used by CPython to
> efficiently implement len() for C-level objects without having to do
> full Python method resolution and dispatch for each call.
>
> you could of course turn len() into a __len__() helper (or even
> sequencetools.len(), if you prefer) for cases where this matters, or
> even reserve the "len" method name, but I'm not sure how that would
> make things *simpler* than they are today.
>
> I'm convinced that it's better for people to get over that silly notion
> that writing x.foo() is somehow always "better" than writing foo(x), in
> a language that actually supports both forms.
>
> (if I'd have to chose between foo(x) and x.foo(), I'd rather get foo(x)
> with multiple dispatch than today's x.foo() single dispatch, but that's
> probably too radical for Python 3000 ;-)

Same here. I've tended to write mostly-functions for a long time, and
PJE's RuleDispatch made it even more compelling to do things that way.
It also made it really easy to learn Erlang and get accustomed to its
pattern matching. All they have is functions and modules, and it works
out rather well because of pattern matching (essentially generic
functions). Instead of classes you just keep the state as a parameter.

-bob