Hello, On Mon, 30 Mar 2020 12:37:48 -0700 Andrew Barnert <abarn...@yahoo.com> wrote:
> On Mar 30, 2020, at 12:00, Paul Sokolovsky <pmis...@gmail.com> wrote: > > Roughly speaking, to support efficient appending, one need to > > be ready to over-allocate string storage, and maintain bookkeeping > > for this. Another known optimization CPython does is for stuff like > > "s = s[off:]", which requires maintaining another "offset" pointer. > > Even with this simplistic consideration, internal structure of > > "str" would be about the same as "io.StringIO" (which also needs to > > over-allocate and maintain "current offset" pointer). But why, if > > there's io.StringIO in the first place? > > Because io.StringIO does _not_ need to do that. It’s documented to > act like a TextIOWrapper around a BytesIO. You miss the point of my RFC - it says it *can* do that, for free. And it *can* be documented as a class to perform very reasonable string construction across various Python implementations. And any Python implementation providing StringIO can pick it up very easily. I hear you, you say "no need". Noted, thanks for detailed feedback. (It's p.4.1 in the RFC, "there's no problem with CPython3, so there's nothing to fix"). [] -- 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/LM7VV66FGB3NV3KMK7OENWHABVWMULHV/ Code of Conduct: http://python.org/psf/codeofconduct/
