Methods vs. Functions (Re: [Python-Dev] A house upon the sand)

Guido van Rossum
Mon, 27 Nov 2000 18:58:52 -0500

> 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
> 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

--Guido van Rossum (home page: