[Python-Dev] Re: copy, len and the like as 'object' methods?

Paul Prescod paulp@ActiveState.com
Wed, 22 Aug 2001 18:08:40 -0700


Ka-Ping Yee wrote:
> 
>...
> 
> Hmm.  And what of, say, abs(-3)?  Should that be -3.abs()?

The former is more in-line with traditional mathematical notation. I
think that counts for something. And anyhow, abs is not fully
polymorphic so it is a little bit of a different case.

> Would you also argue for [1, 2, 3].repr() and "abc".hash()?

Yes. But hashing and repring are done much less often than taking the
length. So I wouldn't worry about them...in this round anyhow. Plus repr
has a first-class syntax so the function is kind of redundant already!

> Where do you draw the line? 

If a function takes a single argument that is a Python object and
immediately dispatches to a magic method, and it is "important" enough
to be a builtin, then it should probably just be a method. What is the
point of hiding what is really going on -- a method call!

>  Maybe my habits are too ingrained
> at this point, but i kind of like the boundary between __methods__
> and ordinary methods... it would somehow bug me to have all these
> methods like abs, len, hash crowding in on my ordinary-method
> namespace.

I can appreciate that your tastes are different from mine...in fact I
said something similar to David when he first suggested it to me but on
reflection it seemed such a subtle thing when compared against the
weirdness of the definition of len:

def len(obj):
   return obj.__length__()

It does a little bit more but not much! If you put that in a module you
wrote you would consider it a little bit bizarre, useless and confusing.
Plus it is another indirection which saps a tiny bit of performance for
nothing.
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook