[Python-Dev] functions vs methods (was Re: trunc()) (original) (raw)

Brett Cannon brett at python.org
Sun Jan 27 22:06:05 CET 2008

On Jan 27, 2008 12:53 PM, Aahz <aahz at 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, listofstrings) 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 listofstrings] 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

More information about the Python-Dev mailing list