And StringIO is already an implementation of the stream protocol (that's its whole point).
So IIUC your idea here, you think it would be good to have an efficient way to building strings that follows the string protocol: actually, + and += in this context is really the sequence protocol:
In [11]: lst = [1,2,3]
In [12]: lst += [4,5,6]
In [13]: lst
Out[13]: [1, 2, 3, 4, 5, 6]
In [14]: tup = (1,2,3)
In [15]: tup += (4,5,6)
In [16]: tup
Out[16]: (1, 2, 3, 4, 5, 6)
In [17]: strin = "123"
In [18]: strin += "456"
In [19]: strin
Out[19]: '123456'
Which is why I suggested that the way to get what you want would be a mutable string, rather than a single, out of place, addition to StringIO.
And a StringBuilder class would be another way.
Either way, I think you'd want it to behave as much like a string as it could, rather than like a stream, with one added feature.
However: as it happens strings are unique in Python: I *think* they are the only built in "ABC" with only one implementation (that is, not only type with no ABC :-) ): they are not duck-typed at all (disregarding the days of Python2 with str and unicode). And as far as I know, they are not in any commonly used third party library either. This is not the case even with numbers: we have integers and floats, and other numbers in third partly libs, such as numpy (and had the __index__ dunder added to better support those).
So there is a lot of code, at least in cPython, that is expecting a str, and exactly a str in various places, right down to the binary representation. And cPython implementation aside, thanks to strings being a sequence of themselves, They are often type checked in user code as well (to distinguish between a string and, e.g. a list of strings). I know in my code, checking for strings is the ONLY type checking I ever do.
So that means a StringBuilder may be the way to go: focused use case and no other type could really be used in place of strings very much anyway.
This all made me think *why* do I type check strings, and virtually nothing else? And it's because in most otehr places, if I want a given type, I can just try to make it from teh input:
x = float(x)
i = int(i)
arr = np.asarray(np)
but:
st = str(st)
doesn't work because ANY object can be made into a string.
Makes me wonder if we could have an "asstr()", that acted like numpy's asarray: if it's an array already, it just passes it through. if it's not, then it tries to build an array out of it.
Of course, there are currently essentially no objects that ducktype strings now, so, well, no use case.
SideNote: I jsut noticed that PYthon2 actually HAD a MutableString:
Which was clearly (from the docs) not actually designed to be used :-)
-CHB