On Jan 27, 2008 12:53 PM, Aahz <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
