Victor Ng wrote: [snip]
So, what I'm proposing is merging the vlibxml2 into lxml's 'src' directory, but being its own package. What do you think? Of course we'd also need to figure out what to do with the extensions package; I'm not familiar enough with vlibxml2's source layout to know where everything goes. Ideas?
Sounds good to me. Phillip has set me up on SVN at codespeak now. I'll check in my code tonight, make a branch and play around with source layout and maybe we can come to an agreement on how everything should fit together.
Great!
If you'd like and can come up with a good name, we could rename the whole 'lxml' distribution into something else that may be more neutral. We could then call it all <foo>.libxml2, <foo>.libxslt, <foo>.dom and <foo>.elementtree. I.e. one top level package to make the namespaces clear, with sub-modules/packages that offer particular functionalities. vlibxml2 would become 'libxml2'. Though perhaps this all promises *too* much API compatibility with the original libxml2/elementtree/etc for us to feel comfortable about?
Naming is pretty low on my priority list.
True: we can always reorganize in the future. The nice thing of having a single outer namespace package is that you're free to name anything in the project whatever you like. I'm doing this with the 'lxml' namespace, basically.
I don't want to have vlibxml2 renamed to libxml2 mainly because libxml2 will have a superset of features for the foreseeable future.
True. Anyway, keep the project namespace package in mind -- it's a pattern one sees in many modern Python projects and does make avoiding namespace clashes more easy.
I'm going to take a crack at learning SWIG to see if I can close that gap a little faster though. Maybe close the gap entirely. :)
I've seen SWIG in use for some projects, and while it can work, there's nothing that beats manual control. A predecessor to PyGame, PySDL, used SWIG, but the manually written PyGame is much nicer as it's more Pythonic. The nice thing about Pyrex is that it makes such manual control much easier than using straight C. Then again, the requirements for vlibxml2 may be low-level enough to make SWIG worth looking at. What about things like proper Python unicode strings in the API for instance instead of UTF-8, though? What about sensible Python exceptions handling when things go wrong? SWIG may have some features to deal with this, but it'll get tricky.. Regards, Martijn