This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients jcon, loewis, mark.dickinson, pitrou, rhettinger
Date 2011-10-03.11:58:02
SpamBayes Score 1.7113434e-06
Marked as misclassified No
Message-id <1317642873.3670.2.camel@localhost.localdomain>
In-reply-to <1317642254.13.0.480486303814.issue12911@psf.upfronthosting.co.za>
Content
> > That's another possibility. But we'd have to expose a 
> > C API anyway, and this one is as good as any other.
> 
> No, it's not: it's additional clutter. If new API needs to be added,
> adding it for existing structures is better. Notice that you don't
> *need* new API, as you can use StringIO just fine from C also.

Yes, but using StringIO without a dedicated C API is more tedious and
quite slower.

> > Note that StringIO will copy data twice (once when calling 
> > write(), once when calling getvalue()), while ''.join() only once (at 
> > the end, when concatenating all strings).
> 
> Sounds like a flaw in StringIO to me. It could also manage a list of
> strings that have been written, rather than only using a flat buffer.
> Only when someone actually needs a linear buffer, it could convert it
> (and use a plain string.join when getvalue is called and there is no
> buffer at all).

That's what I thought as well. However, that's probably too much for a
bugfix release (and this issue is meant to allow test_bigmem to pass on
3.x).
History
Date User Action Args
2011-10-03 11:58:03pitrousetrecipients: + pitrou, loewis, rhettinger, mark.dickinson, jcon
2011-10-03 11:58:02pitroulinkissue12911 messages
2011-10-03 11:58:02pitroucreate