Re: StringIO proposal: add __iadd__

[Raymond Hettinger] > > The StringIO API needs to closely mirror the file object API. > > Do you want to change everything that is filelike to have += > > as a synonym for write()? [Paul Rubin] > Why would they need that? Polymorphism > StringIO objects have getvalue() but other > file-like obje

Re: StringIO proposal: add __iadd__

On Sun, 29 Jan 2006, Alex Martelli wrote: > Paul Rubin wrote: > >> 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. > > By all means, the C

Re: StringIO proposal: add __iadd__

[EMAIL PROTECTED] (Alex Martelli) writes: > Not really: <<'s point is to allow chaining, f< no such "advantage" (or disadvantage, as the case may be). Hmm, ok. I've always found << repulsive in that context though, so won't suggest it for Python. -- http://mail.python.org/mailman/listinfo/pyth

Re: StringIO proposal: add __iadd__

Paul Rubin wrote: > And is making += a synonym for write() on other file objects really > that bad an idea? It would be like C++'s use of << for file objects > and could make some code nicer if you like that kind of thing. Not really: <<'s point is to allow chaining, f

Re: StringIO proposal: add __iadd__

"Raymond Hettinger" <[EMAIL PROTECTED]> writes: > The StringIO API needs to closely mirror the file object API. > Do you want to change everything that is filelike to have += > as a synonym for write()? Why would they need that? StringIO objects have getvalue() but other file-like objects don't.

Re: StringIO proposal: add __iadd__

[Paul Rubin] > 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. > > Any thoughts? The StringIO API needs to closely mirror the file object API. Do you want to change everything that is filelike to ha

Re: StringIO proposal: add __iadd__

Paul Rubin writes: > etc., probably not worth the trouble. Based on examining StringIO.py, > on my current computer (512MB ram), with 100 million items, it looks Better make that 200 million. -- http://mail.python.org/mailman/listinfo/python-list

Re: StringIO proposal: add __iadd__

[EMAIL PROTECTED] (Alex Martelli) writes: > > That depends on how much ram you have. You could try a billion items. > Let's see you try it If you want me to try timing it with a billion items on your computer, you'd have to set up a suitable account and open a network connection, etc., probably n

Re: StringIO proposal: add __iadd__

Paul Rubin writes: > > After all, how do you think StringIO is implemented internally? A list > > of strings and a ''.join at the end are the best way that comes to mind, > > I'd have used the array module. I just checked the implementation and it uses ''.join combined

Re: StringIO proposal: add __iadd__

Paul Rubin wrote: ... > > Absolutely wrong: ''.join takes less for a million items than StringIO > > takes for 100,000. > > That depends on how much ram you have. You could try a billion items. Let's see you try it -- I have better things to do than to trash aroun

Re: StringIO proposal: add __iadd__

[EMAIL PROTECTED] (Alex Martelli) writes: > Absolutely wrong: ''.join takes less for a million items than StringIO > takes for 100,000. That depends on how much ram you have. You could try a billion items. > It's _so_ easy to measure...! Yes but the result depends on your specific hardware a

Re: StringIO proposal: add __iadd__

Paul Rubin wrote: ... > ''.join with a list (rather than a generator) arg may be plain worse > than python StringIO. Imagine building up a megabyte string one > character at a time, which means making a million-element list and a > million temporary one-character stri

Re: StringIO proposal: add __iadd__

[EMAIL PROTECTED] (Alex Martelli) writes: > > Is there some sound reason cStringIO acts differently from > > StringIO? I'd expect them to both do the same thing. > > I believe that cStringIO tries to optimize, while StringIO doesn't and > is thereby more general. I'm not sure what optimizations

Re: StringIO proposal: add __iadd__

Scott David Daniels <[EMAIL PROTECTED]> wrote: > Alex Martelli wrote: > > 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 > > Pyth

Re: StringIO proposal: add __iadd__

Paul Rubin wrote: > [EMAIL PROTECTED] (Alex Martelli) writes: > > 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

Re: StringIO proposal: add __iadd__

Alex Martelli wrote: > 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/pyStr

Re: StringIO proposal: add __iadd__

Paul Rubin wrote: > I've always found the string-building idiom > > temp_list = [] > for x in various_pieces_of_output(): > v = go_figure_out_some_string() > temp_list.append(v) > final_string = ''.join(temp_list) > > completely repulsive. As an alternative I suggest > >t

Re: StringIO proposal: add __iadd__

[EMAIL PROTECTED] (Alex Martelli) writes: > 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? I see that 'a' + u'b' = u'ab', whi

Re: StringIO proposal: add __iadd__

Paul Rubin 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--

Re: StringIO proposal: add __iadd__

[EMAIL PROTECTED] (Alex Martelli) writes: > 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)...? Sure, + can also be supported. Adding two StringIO's,

Re: StringIO proposal: add __iadd__

Paul Rubin 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)

StringIO proposal: add __iadd__

I've always found the string-building idiom temp_list = [] for x in various_pieces_of_output(): v = go_figure_out_some_string() temp_list.append(v) final_string = ''.join(temp_list) completely repulsive. As an alternative I suggest temp_buf = StringIO() for x in various_