On 16-Nov-04, at 01:01 PM, Martijn Faassen wrote:
I'm very curious to hear your thinking on using vlibxml2's system for memory management as a base for the rest of lxml's pyrex based stuff (etree, the dom). Do you think this would be easy or would a fairly large restructuring still be necessary? I guess I need to sit down and try to get some sample code working.
I think the best way to do things would be to sit lxml on top of vlibxml2. We get a couple benefits this way: - vlibxml2 has a critical 'user' so we can use lxml to drive the features that need to be implemented in vlibxml2. Right now - I'm using vlibxml2 but mainly for reading XML documents and slicing them up with XPath which is a small subset of the functions that lxml will need to - one place to worry about memory management. I hate this memory management stuff. If we can keep all the code garbage collection code in one place, it will make life easier for everyone. I _have_ to have the vlibxml2 replaceNode function stabilized by this weekend. vic