Paul Rubin <http://[EMAIL PROTECTED]> wrote: ... > temp_buf = StringIO() > for x in various_pieces_of_output(): > v = go_figure_out_some_string() > temp_buf += v > final_string = temp_buf.getvalue() > > here, "temp_buf += v" is supposed to be the same as "temp_buf.write(v)". > So the suggestion is to add a __iadd__ method to StringIO and cStringIO.
What's the added value of spelling x.write(v) as x += v? Is it worth the utter strangeness of having a class which allows += and not + (the only one in the std library, I think it would be)...? > Any thoughts? I think that the piece of code you like and I just quoted is just fine, simply by changing the += to a write. > Also, I wonder if it's now ok to eliminate the existing StringIO > module (make it an alias for cStringIO) now that new-style classes > permit extending cStringIO.StringIO. I love having a pure-Python version of any C-coded standard library module (indeed, I wish I had more!-) for all sorts of reasons, including easing the burden of porting Python to weird platforms. 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. It would be nice (in Py3k, when backwards compatibility can be broken) to make the plain-named, "default" modules those coded in C, since they're used more often, and find another convention to indicate pure Python equivalents -- e.g., pickle/pypickle and StringIO/pyStringIO rather than the current cPickle/pickle and cStringIO/StringIO. 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;). Alex -- http://mail.python.org/mailman/listinfo/python-list
