Method Underscores?

[John Roth]

"Chris S." <chrisks at NOSPAM.udel.edu> wrote in message 
news:9dIdd.3712$EL5.3057 at trndny09...
> 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, but would using myclass.len() 
> instead of myclass.__len__() really cause Python considerable harm? 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?

Languages that make everything methods tend to have
two characteristics in common: a single base class, and
no facility for procedural programming.

Python does not have a single base class, and one of its
strong points is that it's a multi-paradigm language. You can
use it for procedural programming without having to put
everything in the object paradigm. People quite frequently
do this for scripts.

In single base class languages, the top object in the
hierarchy is a hod-podge of methods that have no
relationship other than the language designer's decision
that the function is fundamental enough that it needs to
be available to every object, whether it needs it or not.

It would be technically possible (and relatively easy for
anyone with a bit of experience with working on Python's
internals) to add, for example, .len() to the object class.
Would this break anything? Unlikely in most cases
(there is one edge case I know of where it would).  Alex Martelli's
comment elsewhere in this thread assumes one would also
remove it from the builtins, which would of course break
everything in sight.

Removing it from the builtins is equivalent to eliminating
the multi-paradigm nature of Python: you could no longer
do effective procedural programming without the builtins!
This is simply not going to happen: it would be a completely
different language. Discussing it is futile.

Also, the new .len() method would only be available
to new style classes written in Python, and then only
if the author of some subclass had not decided to implement
their own len() method with different semantics. The
first of these two objections goes away in Python 3.0,
where old style classes are eliminated. The second,
however, is a difficulty that all "pure" OO languages
need to deal with, and there is no real good way of
handling it (meaning obvious, works all the time
everywhere, and upward compatible without breaking
anything.).

Having a parallel structure where a large number of
builtins are also implemented as methods on object
violates Python's basic philosophy in at least two
ways: there should only be one (obvious) way to do
something, and things should work the same way
everywhere.

All that said, I'd like to see some of the builtins
as methods on object, but since it's not going
to happen, it's not worth worrying about.

John Roth