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 loewis
Recipients jcon, loewis, mark.dickinson, pitrou, rhettinger
Date 2011-10-03.11:44:13
SpamBayes Score 7.763249e-07
Marked as misclassified No
Message-id <1317642254.13.0.480486303814.issue12911@psf.upfronthosting.co.za>
In-reply-to
Content
> It's not a container type, just a small C struct that 
> gets allocated on the stack. Think of it as a library, like stringlib.

That's what I call a container type: a structure with a library :-)

> 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.

> 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).
History
Date User Action Args
2011-10-03 11:44:14loewissetrecipients: + loewis, rhettinger, mark.dickinson, pitrou, jcon
2011-10-03 11:44:14loewissetmessageid: <1317642254.13.0.480486303814.issue12911@psf.upfronthosting.co.za>
2011-10-03 11:44:13loewislinkissue12911 messages
2011-10-03 11:44:13loewiscreate