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 ;-) </F> _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
