[Python-Dev] deprecating string module?

Guido van Rossum guido@python.org
Fri, 31 May 2002 00:35:22 -0400


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