Re: [boost] Extending Boost.Python with NumPy support

On 03.10.2016 08:13, Rob Stewart wrote:

On October 2, 2016 6:20:27 PM EDT, Stefan Seefeld wrote:

...

Right, I know that text (being the Boost.Python maintainer) :-) I'm fully confident concerning the new code's quality. What makes me wonder (and triggered my mail) is that the change in its current form will introduce

* a new library (boost_numpy) How is a new library part of Boost.Python? It seems a review is needed for that.

Conceptually it's not a new library. It's the result of some refactoring / extension of Boost.Python. The API provided by the boost/python/numeric.hpp header is *very* old and outdated, as that API hasn't kept up with the evolution of the equivalent APIs inside Python. Everyone in the Python world who's doing numeric computations uses NumPy, so using Boost.Python wrappers for that instead of boost/python/numeric.hpp is the obvious choice. But since not every Boost.Python user needs NumPy support, I don't want to build that into the libboost_python library itself ("don't pay for what you don't need"), but rather compile a separate library next to it.

...

* a new top-level header (boost/numpy.hpp) * a new top-level namespace (boost::numpy) Those are part of the first item as I see them.

Not quite: Whether to build a single binary or not is a practical choice, and there are other cases where a single module can produce additional (optional) libraries depending on whether prerequisite libraries are available at build time (example: Boost.MPI and its Python bindings) Whether the new API lives in a top-level namespace (boost::numpy) or not (boost::python::numeric or boost::python::numpy) is secondary IMO. If that choice influences whether I have to go through a formal review process I'll surely opt for the simpler and more expedient choice. (But to be honest, I'm not so much afraid of the review itself as of the ETA for it, given the current pace at which reviews are done.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...