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,
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/