The Python standard library and PEP8

[Emmanuel Surleau]

> Perhaps in statically typed languages. Python is dynamic, so a x.length()
> requires a method lookup and that's expensive. len(x) on the contrary, can
> be optimized on a case by case basis -- it DOESN'T translate to
> x.__len__() as some might think.
> See
> http://www.python.org/doc/faq/general/#why-does-python-use-methods-
for-some
>-functionality-e-g-list-index-but-functions-for-other-e-g-len-list

I don't know... the gist of the FAQ you link to is "that's legacy code and we 
don't want to change it in order not to break code". It doesn't try to justify 
the continued existence of len() and friends with technical arguments. I'll 
grant you that avoiding a method lookup is cheaper, another question is 
whether the difference would be noticeable in practice. I'd say that if 
methods were such a bad thing, that would put in question the 
implementation of the whole OO paradigm in Python, no?

> On a side note, there is an alternative to dir(), more human-friendly:
> http://inky.github.com/see/
>
> py> see("a")
>    ?   []   in   +   *   %   <   <=   ==   !=   >   >=   len()
> .capitalize()
>    .center()   .count()   .decode()   .encode()   .endswith()
> .expandtabs()
>    .find()   .format()   .index()   .isalnum()   .isalpha()   .isdigit()
>    .islower()   .isspace()   .istitle()   .isupper()   .join()   .ljust()
>    .lower()   .lstrip()   .partition()   .replace()   .rfind()   .rindex()
>    .rjust()   .rpartition()   .rsplit()   .rstrip()   .split()
> .splitlines()
>    .startswith()   .strip()   .swapcase()   .title()   .translate()
> .upper()
>    .zfill()
>
> You can see len() there.

Nice! That's indeed more readable than dir().

Cheers,

Emm