> 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 -- http://mail.python.org/mailman/listinfo/python-list
