I agree with the arguments the OP brings forward. Maybe, it should be the case of having an `StringIO` and `BytesIO` subclass? Or better yet, just a class that wraps those, and hide away the other file-like methods and behaviors? That would keep the new class semantically as a string, and they could implement all of the str/bytes methods and attributes so as to be a drop-in replacement - _and_ add a proper `__setitem__` so that one could have a proper "mutable string". It ust would use StringIO/BytesIo as its "engine". Such code would take like, 100 lines (most of them just to forward/reimplement some of the legacy str methods), be an effective drop-in replacement, require no change to Python - it could even be put now in Pypi - and, maybe, even reach Python 3.9 in time, because, as I said, I agree with your points. On Mon, 30 Mar 2020 at 12:06, <jdveiga@gmail.com> wrote:
I completely agree with Andrew Barnert.
I just want to add a little comment about overriding the `+=` (and `+`) operator for StringIO. Since StringIO is a stream --not a string--, I think `StringIO` should continue to use the common interface for streams in Python. `write()` and `read()` are fine for streams (and files) and you can find similar `write` and `read` functions in other languages. I cannot see any advantage on departing from this convention. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LFGQVJ... Code of Conduct: http://python.org/psf/codeofconduct/