Merge with Boost.Python
stefanseefeld opened this issue · 10 comments
I'm considering ways to merge Boost.Numpy into Boost.Python. Is this a project you'd be interested participating in ? (I'm now the Boost.Python maintainer, working on a few improvements there, notably to make it easier to build Boost.Python stand-alone with only minimal dependencies towards (the rest of) Boost.
Yes, I'm interested
On Mon, Jun 27, 2016 at 10:56 AM, Stefan Seefeld notifications@github.com
wrote:
I'm considering ways to merge Boost.Numpy into Boost.Python. Is this a
project you'd be interested participating in ? (I'm now the Boost.Python
maintainer, working on a few improvements there, notably to make it easier
to build Boost.Python stand-alone with only minimal dependencies towards
(the rest of) Boost.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#65, or mute the thread
https://github.com/notifications/unsubscribe/AAHK0CvJeLUqGBmHve03n2kWo59NQw-Bks5qP-SRgaJpZM4I_LjH
.
Those who don't understand recursion are doomed to repeat it
I'd love to see that happen, and I'd be willing to commit some effort towards it.
I should qualify that by adding that this is partially because I'd like to get out of the business of supporting Boost.NumPy myself (my projects are now all using Swig or pybind11), without abandoning it. Given that most of the issues these days are build system issues where the Boost libs can't be identified properly, merging that with the Boost.Python build seems like a big win.
Is there something like ndarray which works with pybind11? pybind11 by
itself looks interesting, but the c++ side ndarray API has almost no
functionality.
On Mon, Jun 27, 2016 at 11:05 AM, Jim Bosch notifications@github.com
wrote:
I'd love to see that happen, and I'd be willing to commit some effort
towards it.I should qualify that by adding that this partially because I'd like to
get out of the business of supporting Boost.NumPy myself (my projects are
now all using Swig or pybind11), without abandoning it. Given that most of
the issues these days are build system issues where the Boost libs can't be
identified properly, merging that with the Boost.Python build seems like a
big win.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#65 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAHK0NDVxgsFHl1HmtIdRTQl1rx7qbgHks5qP-bAgaJpZM4I_LjH
.
Those who don't understand recursion are doomed to repeat it
Yes. As it happens, Boost.Build was a huge blocking issue for me. Having just now managed to set up a SCons-based build system that supports stand-alone builds, I think we are now in a much better position to work on different improvements.
I'm aware of pybind11, and am considering ways to incorporate its features into Boost.Python, so long as this doesn't affect backward compatibility. I realize that one of the biggest (perceived) issues with Boost.Python is its entanglement with the rest of Boost; an issue which I'm trying to address (incrementally), notably by allowing stand-alone builds, as well as by adding C++11 support that may make a number of other Boost dependencies obsolete.
As far as Boost.NumPy is concerned, the first thing for me to figure out is whether it would be acceptable at all to incorporate its features into Boost.Python without having to pass by a formal submission. Incorporating individual patches then becomes the easy part.
@nbecker: ndarray doesn't work with with pybind11 yet, but some combination of @pschella and I will probably be adding that in the coming months as we work towards switching some of our Swig-based code to pybind11.
@stefanseefeld: You've already addressed the biggest issues with Boost.Python (IMO) by giving it a maintainer (and the community owes you a huge thanks). That came just a bit late for my organization (http://dm.lsst.org/) to consider switching to it instead of pybind11, but if your top priority on Boost.Python is backwards compatibility it sounds like there's likely to be a niche for both projects, and they'll probably make each other stronger.
I would like to add my two cents. The best of both worlds would be to have both a pybind11 and a Boost.Python interface to numpy. The use of Boost.Build for Boost.Python has always been a problem for me. (I use cmake for all of my C++ projects, so I was not a fan of scons either. That is why I worked on the cmake build to Boost.Numpy.)
So having a boost-free pybind11 implementation of ndarray would be great. Then if there is compelling functionality that comes with Boost.Python, that would be a bonus.
I have just done a first attempt at merging this into Boost.Python. A (temporary, trial) branch is https://github.com/stefanseefeld/boost.python/tree/numpy.
Note that the boost::numpy namespace has become boost::python::numpy, and the headers have moved accordingly to boost/python/numpy/. (This was mostly to avoid having to go through a full formal review process as a 'Boost.Numpy' library would be considered an independent project.
So far all looks good, and I plan to merge this into upstream master in time for the Boost 1.63 release, unless there are serious objections / complications.
Any feedback is much appreciated.
Thanks! I left one very minor comment on one of your commits, but overall this looks great.
Once you've merged this into the Boost.Python mainline, I'll put a big deprecation warning in the Boost.NumPy readme, and I'll make it even more prominent when this is included in a Boost release.
Thank you !
And just for avoidance of doubt: if there are any features in Pybind11 that you'd like to see in Boost.Python, please let me know (ideally as a feature request on the tracker). I have started to work on some modernizing (right now simply adding some C++11 feature support), and such feature requests will greatly help focus any future effort.
The merge just landed in Boost.Python's master branch (https://github.com/boostorg/python/tree/master) and will thus be part of the upcoming 1.63 release. (Docs are already online: http://boostorg.github.io/python/doc/html/numpy/index.html)