> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4