Hello, On Tue, 31 Mar 2020 16:28:22 +1100 Steven D'Aprano <steve@pearwood.info> wrote:
On Mon, Mar 30, 2020 at 10:08:06PM -0700, Guido van Rossum wrote:
On Mon, Mar 30, 2020 at 10:00 PM Steven D'Aprano <steve@pearwood.info> wrote:
it’s optimized for a different use case than string building,
It is? That's odd. The whole purpose of StringIO is to build strings.
I misspoke: it is not the *whole* purpose. See below.
Steven, I appreciate keeping up discussion from the same angle as I see it. (I read the thread in chronological order, and see that I could save on some replies, just +1's your.) For the last sentence above, I could offer an explanation "from the other side". Just imagine that we took io.StringIO and: 1. Limit its constructor to StringIO(). (No parameters, no universal newlines!) 2. Leave only the methods .write(), .getvalue(), and remove all other methods. Now, the *whole* purpose of such a class would be string building, it literally can't do anything else. Suppose we now indeed split off such a class, and named it StringBuilder. We'd now have an bit of issue explaining why all that was done. "StringBuffer implements subset of the functionality of StringIO". D'oh. Looking on the implementation side, this StringBuffer class would also have the machinery already present in StringIO, like backing store for accumulated content, size/offset into this backing store. Yes, perhaps it could have code a bit more specialized for just writing and no reading, but is it worth code duplication? So, the core of the criticism seems to be that StringIO was designed for "another purpose" and that it "does much more". It's a bit strange argumentation that a more generic/featureful object can't (just can't) be used for subset of its functionality, you should be always concerned that it can do much more. It's a bit strange logic, akin to "lists are intended to store arbitrary objects, so if you store integers in them, you're doing something wrong". Let's get to our StringBuffer class as constructed above. Now that it doesn't have "IO" at the end, we perhaps can give up and add __iadd__ method to it, having the same semantics as .write(), but returning self (thanks for correction!). But if we can do that, then with the arguments above re: entity and code duplication, perhaps we can do that on the original StringIO. About the only thing that can preclude that is an irrational belief that given that originally it was intended for more general usecase, then we can't, just can't, nudge to make it more comfortable for a subset of its usage. -- Best regards, Paul mailto:pmiscml@gmail.com