On Sat, 27 May 2006, [EMAIL PROTECTED] wrote:
When you started writing your wrappers, did you consider the Boost.Python system? I'm considering it for some stuff of my own, but haven't looked at it much. Is there a glaring technical shortcoming that makes it unsuitable for PyLucene (or other large projects), or did you just not want to introduce excessive dependencies on PyLucene?
I did not consider Boost.Python or any other such package. The main motivation in de-swigging PyLucene was to get rid of a dependency. There are also some technical considerations that nudged me over, namely that it's not C++ that's being wrapped but Java that looks like C++ via CNI. Pointer ownership and dynamic typing is implemented by Java already, I didn't need SWIG to add its own version of that on top of it. Over the past year, I got the opportunity to get very familiar with the python C type API and ultimately felt rather comfortable writing the wrappers by hand. And finally, the amount of work in maintaining the SWIG interface in light of the constant changes in the SWIG package itself eventually exceeded the amount of work in writing the wrappers by hand once. The Java Lucene API is quite stable, after all.
Andi.. _______________________________________________ pylucene-dev mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
