Victor Ng wrote:
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:
Terminology note: lxml - the name of the package we're all working on (if we agree on this). It's a distribution name, and from the Python perspective a namespace package. vlibxml2 - the low-level binding for libxml2, part of lxml. This is the part of lxml that's done first and foundational to the rest of it. We could even call it 'lxml.foundation'. :) Once you're happy with it, we can promote people to use this. etree - the elementtree implementation, part of lxml dom - the DOM implementation, part of lxml Would you be okay with this terminology? Using this terminology, we'd say lxml.etree, lxml.dom, etc should sit upon the foundation offered by lxml.vlibxml2.
- 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
Good point.
- 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.
And this is one of my main concerns, so excellent point. I want this badly.
I _have_ to have the vlibxml2 replaceNode function stabilized by this weekend.
I'm curious to see what etree (for instance) sitting on vlibxml2 would look like. Much of vlibxml2 consists of work to expose the libxml2 API to Python. Another part makes sure the memory management issue is clear. Would etree (for instance) make use of both parts of vlibxml2 (is memory management a lot easier to tackle if vlibxml2's exposed libxml2 API is used), or would just the latter be enough? Regards, Martijn