The Python standard library and PEP8

Emmanuel Surleau emmanuel.surleau at gmail.com
Sun Apr 19 22:58:50 CEST 2009


> 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



More information about the Python-list mailing list