![](https://secure.gravatar.com/avatar/63756693d9b79ff633f86ff5672652e9.jpg?s=120&d=mm&r=g)
On 11/10/12 18:34, Stefan Behnel wrote:
Actually, I'd love to see someone implement a magic API like this:
# open an "XMLFile" object that knows about XML serialisation with xmlfile("somefile.xml", encoding='utf-8') as xf: # generate an element (the root element) with xf.Element('root-tag') as root_element: # generate content, e.g. through iterparse for element in generate_some_elements(): # serialise generated elements into the XML file xf.write(element)
That looks like it should be totally trivial to do, but would make the above use case way simpler and safer. Thanks everyone for the comments. However, I really meant it the way I showed above. The use case is to freely (and efficiently) mix in-memory
Stefan Behnel, 01.11.2012 22:56: trees with incrementally generated content, and to safely write everything out into a file as it is being generated.
Hi Stefan, Maybe I'm not seeing something obvious, but how would this work in the WSGI case where you have to yield bunch of strings instead of writing to a file-like object? From the WSGI spec (http://www.python.org/dev/peps/pep-0333/#the-write-callable): """ New WSGI applications and frameworks *should not* use the write() callable if it is possible to avoid doing so. The write() callable is strictly a hack to support imperative streaming APIs. In general, applications should produce their output via their returned iterable, as this makes it possible for web servers to interleave other tasks in the same Python thread, potentially providing better throughput for the server as a whole. """ Emphasis not mine. Best, Burak