Steven D'Aprano writes:
[I]t ought to be clear from Paul's well-written and detailed post, which carefully explains what he wants.
Whose value to Python I still don't understand, because AFAICS it's something that on the one hand violates TOOWTDI and has no parallels elsewhere in the io module, and on the other hand is trivial to implement for any programmer who really thirsts for StringIO.__iadd__. Unless there are reasons why a derived class won't do? I agree there seem to be possible space performance issues with str.join that are especially painful for embedded applications (as came out later in the thread I believe), but if those are solved by StringIO, they're solved by StringIO. So the whole thing seems to be a cosmetic need for niche applications[1] for a niche platform[2] that is addressed by a 4-line class definition[3] for users who want the syntactic sugar. Me, I'm perfectly happy with StringIO.write because that's what I expect from the io module. FWIW YMMV of course. Footnotes: [1] I don't even use strings at all in any of my adafruit applications! [2] OK, that's going too far, sorry. Embedded matters, their needs are real needs, and they face tight constraints most of us rarely need to worry about. It's still at present a minority platform, I believe, and the rest of the sentence applies AFAIK. [3] Paul's "exact alias of .write() method", which can be done in 1 line, fails because .write() doesn't return self. Thanks, Serhiy. In the stdlib we might even want a check for "at end of buffer" (.write() can overwrite Unicode scalars anywhere in the buffer). That's definitely overengineering for a user, but in the stdlib, dunno.