[Python-Dev] .len() instead of __len__() in Py3.0

[Oleg Broytmann]

On Mon, Mar 06, 2006 at 05:33:23AM -0800, Michael Chermside wrote:
> Oleg Broytmann writes that he thinks methods are inherently "better" than
> methods.

   "...better than *functions*."

> In defense of functions, my first exhibit is the following snippet of Java
> code:
> 
>   /** Returns b^2 - 4ac */
>   public BigDecimal determinant(BigDecimal a, BigDecimal b, BigDecimal c) {
>     return b.multiply(b).subtract(new BigDecimal(4).multiply(a).multiply(c));
>   }

   I never said methods are better than operators. Though to some extent
they are. For example, if you want to grep your sources for ".addArray("
you have much better chances to find what you are looking for comparing
with the case when you grep for "+=". In the latter case you will find too
much.
   But I do not propose to get rid of operator overloading and always use
methods.

>   public int numItems(Object o) {
>     if (o instanceof Collection) { // includes List, Set
>       return ((Collection) o).size();
>     } else if (o instanceof Dictionary) {
>       return ((Dictionary) o).size();
>     } else if (o instanceof CharSequence) { // includes String, StringBuffer
>       return ((CharSequence) o).length();
>     } else if (o instanceof Object[]) {
>       return ((Object[]) o).length;
>     } else {
>       throw new IllegalArgumentException();
>     }
>   }
> 
> The inconsistancy here is amazing...

   The same can easily be written in Python. In absence of builtin function
has_key() and documented method __has_key__() one can write

class MyDict(object):
   def hasKey(self, key):
      ...

other can spell it .has_key() or .haskey(). Still those who want to emulate
dictionaries (to implement mapping protocol) spell it .has_key().
   A real life example. SQLObject has a class SelectResults that partially
implements sequence/iterator protocol. But it doesn't have __len__(),
instead it has method .count(). Look at the first question at
http://svn.colorstudy.com/SQLObject/docs/FAQ.txt , "Why there is no
__len__?" So instead of len(sresults) one must write sresults.count().
   So even the known protocol "len() => __len__()" doesn't prevent the
inconsistency. Sometimes one really needs the inconsistency; in this
particular case because Python internally calls len() on objects, and
implementing __len__() here would be expensive.
   And those who want to be consistent are. They spell .has_key() and
implement __len__(). And if __len__() becomes .len() they will write
.len(), not .size() or .count().

> len() is such a powerful concept applicable across MANY diverse
> kinds of objects

   Only to those already have method __len__(), so why not .len()?

> I just wanted to point out that one of the things I *LOVE* about Python
> is that the design of name resolution in Python ensures that no
> programmer need suffer from the size of the builtin namespace. If you
> never use certain builtins, perhaps "hex" or "super", then go ahead
> and use those as identifiers in your code. Avoid only that portion of
> the builtin namespace that you feel is worth keeping.

   Doesn't work. For example, PyChecker/PyLint would report warnings.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.