[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