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

[Guido van Rossum]

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