On Wed, Apr 1, 2020 at 1:31 PM Paul Sokolovsky <pmiscml@gmail.com> wrote:
In short: a mutable string would satisfy the requirements of a "string builder", and more.
Thanks for the detailed explanation. For me, a canonical example of a feature of "mutable string" would be:
s = MutStr("foo") s[0] = "b"
This parallels the difference between immutable byte string (bytes) and mutable byte string (bytestring). As you mention, it would go further than that, e.g.:
def foo(s): s.replace_inplace("foo", "bar")
mys = MutStr("foofoo") foo(mys) # expected: barbar print(mys)
But with all that, I don't see why such a "mutable string" would be more suitable for "string builder" pattern.
It would in one small way, which is that it would be usable directly in many (not all by any means) contexts where strings are used, so there would be less need for the .getvalue() call. I'm thinking that it would be more natural for most folks, who are, after all familiar with strings, but not so much StingIO.
And I mentioned a similar effort I made to make a growable numpy array, and, well, it turned out not to be worth it either.
And I'm not surprised at all. That's because "mutability" and "dynamically size change" are actually orthogonal features, one doesn't imply the other.
Sure: numpy arrays are mutable, and they are not re-sizable.
That's why I said that I don't see how a mutable string would be more suitable for my case of a string builder.
nope -- but just as suitable.
I may imagine that one of the ideas is to keep its internal representation simple
yes and no: yes: numpy arrays were designed explicitly to be a wrapper around a regular old C array (pointer :-) ) no: there are also important reasons (views, performance) to not change the actuall memory location of the data in the same array: that is, not resize on the fly like python lists, or C++ arrays do.
"numeric accelerators" which burn thru those numpy arrays with a simple
and regular internal structure and keep Python competitive for "scientific computing".
and, well, numpy itself :-)
(My favorite is https://github.com/sdiehl/numpile ,
I hadn't seen that -- pretty cool. But also really a toy version of numba, which I'm pretty sure was started first. The funny thing is, in this thread, while I dont really see the need for adding += to StringIO to make a string builder, I kind of like the idea of adding += to the File protocol -- for all file-like objects. I like the compactness of: with open(filename, 'w') as outfile: a_loop_of_somesort: outfile += something And hey, then you'd get your string builder! One other note: if one really wanted a string builder class, a few other things would be nice, like maybe the ___str__ producing the built up string. - CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython