On 11/10/12 18:34, Stefan Behnel wrote:

Stefan Behnel, 01.11.2012 22:56:

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