Hello, On Tue, 31 Mar 2020 17:01:19 -0700 Christopher Barker <pythonchb@gmail.com> wrote: []
So that suggested to me that a mutable string type would completely satisfy your use case, but be more natural to folks used to strings:
message = MutableString("The start of the message") for i in something: buf += "some more message" do_something_with_the_message(message)
And you could do other nifty things with it, like all the string methods, without a lot of wasteful reallocating, particularly for methods that don't change the length of the string. (Though Unicode does make this a challenge!) (and yes, I know, that the "wasteful reallocating" is probably hardly ever, if ever, a bottleneck)
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.
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. 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. I'm not familiar with Numpy enough to comment with high degree of confidence, but I may imagine that one of the ideas is to keep its internal representation simple (ahem, given that there're already multiple dimensions and stuff). And that pays off - while overall JIT story for Python leaves much to be desired, there's a whole bunch of "numeric accelerators" which burn thru those numpy arrays with a simple and regular internal structure and keep Python competitive for "scientific computing". (My favorite is https://github.com/sdiehl/numpile , (a sample of) number-crunching JIT with type inference in 1000 lines. The guy who wrote it went missing in Haskell. And I wonder how many people left Python for the reasons similar to: anything they say, the answer is "in Python, you have to concat string py putting them in an array". Oh btw, in Haskell, that's probably very true ;-) ). -- Best regards, Paul mailto:pmiscml@gmail.com