![](https://secure.gravatar.com/avatar/8b97b5aad24c30e4a1357b38cc39aeaa.jpg?s=120&d=mm&r=g)
Burak Arslan, 18.11.2012 12:19:
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?
The best way to convince other people that your idea is a good one is to implement it.
Also , the reason(s) why this interface does not belong in lxml are not so clear to me, could you elaborate?
The problem is the place where you put this new feature - you attach it to an Element. This means that all code in lxml that deals with tree handling will then have to make sure that any lazily attached subtrees get unfolded when necessary. And since there isn't much code in lxml that does not deal with tree handling in one way or another, we are talking about a *lot* of code here, and certainly a lot of unexpected places from a user's point of view. Apart from that, I wouldn't mind if you can come up with a good way to serialise XML incrementally using 'yield'. Stefan