Hello,
On Tue, 31 Mar 2020 17:01:19 -0700
Christopher Barker <python...@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:pmis...@gmail.com
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/VBBWU2FZS3JUTECECRI6TLFJNVVVYPDA/
Code of Conduct: http://python.org/psf/codeofconduct/
