As others have pointed out, the OP started in a bit of an oblique way, but it maybe come down to this:
There are some use-cases for a mutable string type. And one could certainly write one.
presto: here is one:
Which looks to me to be more a toy than anything, but maybe the author is seriously using it... (it does look like it has a bug indexing if there are non-ascii)
And yet, as far as I know, there has never been one that was carefully written and optimized, which would be a bit of a trick, because of how Python strings handle Unicode. (it would have been a lot easier with Python2 :-) )
So why not?
1) As pointed out, high performance strings are key to a lot of coding, so Python's str is very baked-in to a LOT of code, and can't be duck-typed. I know that pretty much the only time I ever type check (as apposed to simple duck typing EAFTP) is for str. So if one were to make a mutable string type, you'd have to convert it to a string a lot in order to use most other libraries.
That being said, one could write a mutable string that mirrored' the cPython string types as much as possible, and it could be pretty efficient, even for making regular strings out of it.
2) Maybe it's really not that useful. Other than building up a long string with a bunch of small ones (which can be done fine with .join()) , I'm not sure I've had much of a use case -- it would buy you a tiny bit of performance for, say, altering strings in ways that don't change their length, but I doubt there's many (if any) applications that would see any meaningful benefit from that.
So I'd say it hasn't been done because (1) it's a lot of work and (2) it would be a bit of a pain to use, and not gain much at all.
A kind-of-related anecdote:
numpy arrays are mutable, but you can not change their length in place. So, similar with strings, if you want to build up an array with a lot of little pieces, then the best way is to put all the pieces in a list, and then make an array out of it when you are done.
I had a need to do that fairly often (reading data from files of unknown size) so I actually took the time to write an array that could be extended.
Turns out that:
1) it really wasn't much faster (than using a list) in the usual use-cases anyway :-)
2) it did save memory -- which only mattered for monster arrays, and I'd likely need to do something smarter anyway in those cases.
I even took some time to write a Cython-optimized version, which only helped a little. I offered it up to the numpy community.
But in the end: no one expressed much interest. And I haven't used it myself for anything in a long while.
Moral of the story: not much point in a special class to do something that can already be done almost as well with the builtins.
-CHB