> I don't understand how using methods makes multiple > string types easier to deal with. > > Suppose I want to define my own string-like type. How > do I arrange things so that " ".join(x) does the right > thing when x contains instances of my new type? How > is this made easier by the fact that join is a method > of " " rather than a free function? No solution in current Python deals really well with operations of two or more strings that may be of mixed types (the dispatch of binary operators comes closest). The current code checks for both standard string types to overcome this, and that doesn't work for a third, new string type. The point of methods was that homogeneous use (and all operations on a single string like s.lower() are homogeneous) is supported well. Because Python has no dispatch on argument type, the alternative would have been to rewrite the string module to do argument type tests in *all* functions -- and it would not support a third string type at all, not even when used homogeneous. IOW, if I write a function that calls s.lower() for an argument s, I can write a custom string type (e.g. UserString) that will work with f. If I wrote the same function using string.lower(s), I have no hope (short of modifying the string module). --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