Antoine Pitrou <pit...@free.fr> added the comment: > I'm -1 on this approach; I don't think yet another container type is > the right solution, given that we have already plenty of them.
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. > If you want to avoid creating large lists, then the StringIO type > should already provide that. So I wonder why these functions couldn't > be rewritten to use StringIO. That's another possibility. But we'd have to expose a C API anyway, and this one is as good as any other. 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). > If you really want to use this approach, I'd try to avoid allocating > the large list if there are only few substrings. I.e. allocate it only > when flushing, and only if the flush is not the final flush. That's possible, indeed. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12911> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com