The Python standard library and PEP8
Emmanuel Surleau
emmanuel.surleau at gmail.com
Sun Apr 19 16:58:50 EDT 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