On Jan 27, 2008 12:53 PM, Aahz <aahz@pythoncraft.com> wrote:
On Sun, Jan 27, 2008, "Martin v. L?wis" wrote:
Students just asked me why len() is not a method, and I didn't know a good answer; the same holds for many other builtins. This is a clear candidate for a method, IMO.
This is why len() is not a method:
map(len, list_of_strings)
What I don't know is to what extent this argument still holds in the presence of listcomps and genexps:
[s.len() for s in list_of_strings]
However, you still need ``len`` as a function to pass around as a callback in other cases where you need a generic function because the type of your data is not predetermined.
Or you just use ``lambda x: x.len()`` for the callback. And a built-in could easily be created that does what the lambda is doing. I know for me the reason I always thought the built-ins were there on top of using a method naming convention for operator overloading was so that a reasonable default could be provided by the built-in (e.g., iter() being able to work with an object that only provides __getitem__(), on top of its second argument allowing for better iteration control).
In any event, I consider dropping len() from builtins to be gratuitous breakage, even in 3.0.
I don't think anyone is proposing that. -Brett