Hello, On Tue, 31 Mar 2020 17:01:19 -0700 Christopher Barker <pythonchb@gmail.com> wrote: []
However if we're all wrong, and there would be a demand for such a "string builder", then why not write one (could be a wrapper around StringIO if you want), and put it on PyPi, or even just for own lib, and see how it catches on.
Have you done that for your own code and found you like it enough to really want to push this forward?
Yes, that was the progressing: I started with optimizing (my own) code naively written with str += approach, and found that conversion to StringIO.write looks "ugly", so I never finished it. Thinking how to make optimization not affect code quality and clarity, I found that += on StringIO is just it. The issue is that my target implementation is Pycopy (https://github.com/pfalcon/pycopy), which is Python subset. I.e., normal direction is *removing* CPython functionality, not adding to it. Given that it seemed both very obvious addition to Python in general, and went against the normal direction for Pycopy, I decided to share this RFC. As I didn't see any points relevant to Pycopy usecase, I indeed decided to proceed. So, BytesIO.__iadd__()/StringsIO.__iadd__ were added in Pycopy release 3.0.7 (https://github.com/pfalcon/pycopy/releases/tag/v3.0.7) and are documented in the docs: https://pycopy.readthedocs.io/en/latest/library/uio.html#uio.BytesIO.__iadd_... I definitely care about both backwards and forward compatibility between Pycopy and CPython (and other Python implementations). The solution to both problems is very simple: all (well, most) of Pycopy modules are namespaced. So, __iadd__ gets added to uio.BytesIO and uio.StringIO. And there's a backport of "uio" module to CPython: https://github.com/pfalcon/pycopy-lib/blob/master/cpython-uio/uio.py And yes, it's on PyPI: $ python3 -m pip install pycopy-cpython-uio ... $ python3 ...
import uio buf = uio.StringIO() buf += "foo" buf.getvalue() 'foo'
-- Best regards, Paul mailto:pmiscml@gmail.com