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

From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2005-02-16 11:08:26

Somewhere in the E.U., le 16/02/2005

   Bonjour

In article <pan.2005.02.15.10.35.57.65278_at_[hidden]>,
 "Preston A. Elder" <prez_at_[hidden]> wrote:

> 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.

      I agree that a full-fledged library would be the best solution.

> 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 :)

      The biggest stumbling block, however, is that we would need a 
volunteer for that new library (wink wink, nudge nudge)!

> 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 :)

      A secondary point is that, even though it would be a project based 
upon Boost libraries, it has an "unusual" dependency: a language other 
than C++ (well, so does Boost.Python, so this is definitely not a 
show-stopper). I do not know if the same format as for the other 
libraries could be used for the review that library in light of that 
fact (I was not around for the review of B.P).

   Merci

         Hubert Holin