Anyone with an interest in the string functions vs. string methods debate should read this article, which was referenced in comp.lang.python recently:
How Non-Member Functions Improve Encapsulation by Scott Meyers http://www.cuj.com/archive/1802/feature.html
Mr. Meyers presents some very well-reasoned arguments against the everything-should-be-a-method mentality.
Just skimmed it -- seems to be a good argument. (Also for why capwords and zfill aren't worth adding as methods. :-) It would be easy to propose join() as a built-in, and this looks attractive, if it weren't for the existence of os.path.join(). Some people probably write ``from os.path import join'' and once join() is a built-in function, this may be confusing for readers who miss that a different join is imported. (I'm not saying that it breaks existing code -- just that it's confusing to have two joins.) But maybe this is a moot argument since string.join() is already a function. I wonder what Java enthusiasts would say after reading Meyers' article: there *are* no non-member non-friend functions in Java. The best approximation is static methods, but they still live in a class... --Guido van Rossum (home page: http://www.python.org/~guido/)