Hi all,

as part of a project on lxml, I'm building an external element API module (objectify style) as a Pyrex extension. To make this independent of lxml itself, I decided to add an external C-level API that allows external modules to efficiently interface with the lxml module. Usage in other modules will be as easy as including a header file or cimporting a .pxd file in Pyrex, and then calling an init function from the external module. The match is done by comparing char* strings for the function names at initialisation time, so this is pretty future proof (no missing symbols when the C API changes etc.).

This requires some changes in Pyrex, so lxml 1.1 will depend on a patched version (again), until (one day) my patches are accepted upstream. I also published some Python 2.5 related fixes, BTW, to make lxml 1.1 run nicely on Python 2.5. I can't currently test that since I can't get the 2.5 beta versions to work on my machine (broken compiled-in PYTHONPATH). Anyway, at least I got positive feedback that the exception stuff seems to be fixed. The Py_ssize_t fixes are not verified on 2.5, but should also work.

A preliminary version of the patched Pyrex is here: http://codespeak.net/svn/lxml/pyrex/ So, if someone could test lxml with it under 2.5 (preferably on a 64-bit machine) ...

When the lxml C-API is in place, it will be easy to add new functions to it (basically by adding the "public" keyword to a Pyrex C function). So I'd be glad if everyone who thinks this API would be useful for them could propose more functions to be made public. I know specifically that Andreas had a problem with extending the XPath implementation, so maybe there are ways to get this solved at the C level. This thread is the right place to discuss these things.

Regards, Stefan