On 17-Nov-04, at 05:24 AM, Martijn Faassen wrote:
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?
Sounds fine with me. I like vlibxml2 mostly because it's less typing than foundation. :) That and since I'm on OSX - there's already a Foundation package from Objective-C.
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?
The memory management code shouldn't ever have to be used by anyone other than the vlibxml2 package. In retrospect - I really did the whole thing pretty badly, but I've never really done this before so I'll forgive myself - this time. I can't think of a good reason why etree should just have to use the memory management code directly - most of etree's calls to vlibxml2 should be pretty quick. We'll only be adding 2, maybe 3 levels of Python indirection between an etree user and the underlying C implementation anyway - that shouldn't be so bad. Worst case scenario - we find bottlenecks - we profile and fix them. No big deal. vic