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/LFGQVJDOGBBJ7CIYHISM4X4IZDWLGFII/
Code of Conduct: http://python.org/psf/codeofconduct/