Steven D'Aprano writes:

 > [I]t ought to be clear from Paul's well-written and detailed post,
 > which carefully explains what he wants.

Whose value to Python I still don't understand, because AFAICS it's
something that on the one hand violates TOOWTDI and has no parallels
elsewhere in the io module, and on the other hand is trivial to
implement for any programmer who really thirsts for StringIO.__iadd__.
Unless there are reasons why a derived class won't do?

I agree there seem to be possible space performance issues with
str.join that are especially painful for embedded applications (as
came out later in the thread I believe), but if those are solved by
StringIO, they're solved by StringIO.  So the whole thing seems to be
a cosmetic need for niche applications[1] for a niche platform[2] that
is addressed by a 4-line class definition[3] for users who want the
syntactic sugar.  Me, I'm perfectly happy with StringIO.write because
that's what I expect from the io module.  FWIW YMMV of course.

Footnotes: 
[1]  I don't even use strings at all in any of my adafruit applications!

[2]  OK, that's going too far, sorry.  Embedded matters, their needs
are real needs, and they face tight constraints most of us rarely need
to worry about.  It's still at present a minority platform, I believe,
and the rest of the sentence applies AFAIK.

[3]  Paul's "exact alias of .write() method", which can be done in 1
line, fails because .write() doesn't return self.  Thanks, Serhiy.  In
the stdlib we might even want a check for "at end of buffer" (.write()
can overwrite Unicode scalars anywhere in the buffer).  That's
definitely overengineering for a user, but in the stdlib, dunno.
_______________________________________________
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/FBYJRWHOAUP4GQ73ADHBDW4MNDCTK5PM/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to