StringIO proposal: add __iadd__

[Alex Martelli]

Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:
   ...
> > In StringIO's case, it's nice to be able to use the above idiom to
> > concatenate Unicode strings just as easily as plain ones, for
> > example -- cStringIO (like file objects) wants plain bytestrings.
> 
> I wasn't aware of that limitation--maybe cStringIO could be extended
> to take Unicode.  You'd use an encode or decode method to get a
> bytestring out.  

But why can't I have perfectly polymorphic "append a bunch of strings
together", just like I can now (with ''.join of a list of strings, or
StringIO), without caring whether the strings are Unicode or
bytestrings?

> Or there could be a mutable-string class separate
> from cStringIO, to be used for this purpose (of getting rid of the
> list.append kludge).

StringIO works just fine.  Developing (and having to document, learn,
teach, ...) a separate interface just in order to remove StringIO does
not seem worth it.  As for extending cStringIO.write I guess that's
possible, but not without breaking compatibility (code that now uses
that write with unicode strings assuming that they'll get encoded into
bytestrings by the default encoding, and similarly assumes that getvalue
always returns a bytestring, when called on a cStringIO instance); you'd
need instead to add another couple of methods, or wait for Py3k.


> > But I hope the pure-python "reference" modules stay around (and,
> > indeed, I'd love for them to _proliferate_, maybe by adopting some
> > of the work of the pypy guys at some point;).
> 
> Maybe the standard versions of some of these things can be written in
> RPython under PyPy, so they'll compile to fast machine code, and then
> the C versions won't be needed.  But with CPython I think we need the
> C versions.

By all means, the C versions are welcome, I just don't want to lose the
Python versions either (and making them less readable by recoding them
in RPython would interfere with didactical use).


Alex