Method Underscores?

[Andrew Dalke]

Chris S. wrote:
> Is there a purpose for using trailing and leading double underscores for 
> built-in method names? My impression was that underscores are supposed 
> to imply some sort of pseudo-privatization,

They are used to indicate special methods used by Python
that shouldn't be changed or overridden without knowing what
you are doing.

> but would using 
> myclass.len() instead of myclass.__len__() really cause Python 
> considerable harm?

One way to think of it is as a sort of namespace.  Python
needs some specially names methods so that

   print a == b

works correctly ('__eq__' or '__cmp__' for the comparison,
and '__str__' for the stringification for printing).
These could be normal looking functions (meaning without
leading and trailing underscores) but then there's
the worry that someone will override that by accident.

By making them special in a way that most people wouldn't
use normally and formally stating that that range is
reserved for system use, that accident won't happen.
No one will accidently do

    def search(self, name):
      ....
      self.str = "Looking for " + name

only to find latter that 'str' is needed for printing
the stringified version of the instance.

Or consider the other way around.  Suppose everyone decides
we need a new protocol for iteration (pretend this is a
few years ago).  The new protocol requires a new method
name.  What should it be called?

If there isn't a reserved subspace of the namespace then
any choice made will have a chance of interfering with
existing code.  But since "__"+...+"__" is reserved, it
was easy to add special meaning to "__iter__" and know
that no existing code would break.


In most cases the builtin function interface to those methods
does more than forward the call.  For example, iter()
supports both a 2nd parameter sentinel and fall-back support
for lists that don't provide an __iter__.

Of the several dozen special methods, how many would
you really call directly?  It's unlikely you would call
__add__, __mul__, __lt__, ... if only because you would
loose the support for the given operation

 >>> (1).__add__(2)
3
 >>> (1).__add__(2.0)
NotImplemented
 >>>

My guess is you'll have len(), abs(), maybe iter(),
but not many more.  Should only that handful have
non-special names or should all special methods have
non-special names?  If the first, why is that handful
so special?

Do you prefer -x or x.inv() ?


 > As much as I adore Python, I have to admit, I find
> this to be one of the language's most "unPythonic" features and a key 
> arguing point against Python. I've searched for a discussion on this 
> topic in the groups archives, but found little. What are everyone's
> thoughts on this subject?

I've not thought so.  I find it helps me not worry about
conflicting with special method names.  So long as I
don't use the "__"*2 words I'm free to use whatever I want.
Even reserved words if I use getattr/setattr/delattr.

There has been discussion, but I only found a comment
from Guido about 5 years ago saying the "__" are meant for
system names and from Tim Peters about 2 years back saying
that there are only a few methods you might call directly.
And a post of mine saying that I like this feature of Python
compared to in Ruby where special methods are syntactically 
indistinguishable from user-defined methods.

				Andrew
				dalke at dalkescientific.com