[Python-Dev] functions vs methods (was Re: trunc())
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, 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
More information about the Python-Dev
mailing list