On 11/18/12 08:33, Stefan Behnel wrote:
Burak Arslan, 17.11.2012 21:37:
So, does this mean my earlier 'append_generator' suggestion has a green light? Not as part of lxml, especially not as part of the tree API (where it is clearly misplaced). It would substantially complicate the internal implementation without providing a major advantage over other solutions.
If you want to use generators for this, write a dedicated serialisation tool.
I'm not familiar with the internals of lxml, so if you say it'd unnecessarily complicate things, i'd have to take your word for that. But then, does this mean lxml will never get to support a pull interface via generators? Also , the reason(s) why this interface does not belong in lxml are not so clear to me, could you elaborate? Here's another idea: ============== huge_parent = Element("some_call_response") huge_elt = SubElement(huge_parent, "some_huge_array_of_objects") yield serialize_until(huge_elt) yield from generate_xml_fragments() # a lot of 'yield etree.tostring(some_elt)'s yield serialize_after(huge_elt) ============== That's uglier but I think it's better than append_generator because its behaviour is explicit. (you can iterate only once on an element whose children come from generators) It's also an outside API, not part of the tree api. What do you think? Best, Burak