[boost] Re: Organization of Python conversions [was: void * with boost::python]

From: Preston A. Elder (prez_at_[hidden])
Date: 2005-02-15 05:35:57

On Tue, 15 Feb 2005 10:20:08 +0100, Hubert Holin wrote:

> somebody else (the bound library's author or someone else). Or perhaps, 
> putting even less burden on B.P, a Wiki page with that info, referenced 
> from within B.P's documentation. Under this scenario, quality (of the 
> bindings) is not ensured, but perhaps bindings per se lie beyond the 
> purview of Boost, so this point does not matter much.
I'm not sure I like this.  If this module, whether part of Boost.Python or
a separate library (or collection of libraries), it would have a
maintainer, and thus have two distinct advantages.
1) someone who will ensure as major updates happen, these modules are kept
up to date (at least at release time).
and 2) someone who is intimate, at least with boost.python, but probably
at least passingly with the ported functions.

Not to mention that someone who is a maintainer is more likely to ensure a
good job is done, including things like exposing boost exceptions, etc. 
After all, as maintainer, its their name on the code/module :)

As for library dependencies, there is no need for this to be one big
python object (in .so or .dll form).  In fact, it should probably take on
a similar role to what I've created, with a different python object for
each boost module ported (ie. boost::format is separate from
boost::date_time, etc).  If this is kept to, the only dependencies for
each python object would be the boost module it converts (and
boost.python, of course).

I'm assuming if this was done right, a 'boost' directory would be created
under python's object scan path (often /usr/lib/pythonX.X/site-packages or
something), inside that directory would be all the boost interface modules
(one for each boost module, or more if finer granularity is required).

I'm not seeing the issue with library dependencies then.  Though obviously
the python objects would have to be built after boost has completed
building, and not built at all if boost.python was not supported.

This said, it sounds like its a better idea to have as a separate module
to boost.python - even if only for compile-order simplicity and
documentation (which will be interesting, since for the most part, the
documentation would be 'interface is the same as X module, with the
following differences ...').

Thats my not-so-humble opinion :)

-- 
PreZ :)
Founder. The Neuromancy Society (http://www.neuromancy.net)