[python] Making a Python tuple from a Fusion sequence
Hello, I have written a little function that converts any Boost.Fusion sequence into a Python tuple (boost::python::tuple). If a sub-sequence is nested in the sequence, the result will also be a nested tuple (for instance, boost::make_tuple(0, std::make_pair(1, 2), 3) will give (0, (1, 2), 3) in Python). The source code is attached to this mail. The principle is that any sequence previously adapted to Boost.Fusion will become a tuple in Python. So, by including the right boost/fusion/adapted/xxx header, one can convert a pair, a tuple, a boost::array, and obviously any of the sequences provided by Boost.Fusion. For example: #include <boost/python.hpp> #include <boost/fusion/adapted/std_pair.hpp> #include <boost/fusion/adapted/boost_tuple.hpp> #include <boost/fusion/container/generation/make_vector.hpp> #include "make_tuple_from_fusion_sequence.hpp" using namespace boost::python; tuple from_sequence() { return make_tuple_from_fusion( boost::fusion::make_vector( 1, std::make_pair("first", "second"), 2, boost::make_tuple('a', 'b', 'c'), 3 ) ); } BOOST_PYTHON_MODULE(mymodule) { def("from_sequence", &from_sequence); } In Python we get:
import mymodule mymodule.from_sequence() (1, ('first', 'second'), 2, ('a', 'b', 'c'), 3)
Is there any interest in adding this function into Boost.Python? If yes, I can write the doc and tests, clean the source and maybe improve the implementation (for example, I feel that I could avoid the use of m_iteration with a better use of Boost.Fusion...). Regards Bruno
Bruno Lalande wrote:
Is there any interest in adding this function into Boost.Python? If yes, I can write the doc and tests, clean the source and maybe improve the implementation (for example, I feel that I could avoid the use of m_iteration with a better use of Boost.Fusion...).
This looks very useful to me.
Bruno Lalande wrote:
This looks very useful to me.
So only one person interested, not sure it's enough to integrate it :-)
What exactly to you mean by 'adding to boost.python' ? Would this add a dependency, either to boost.python or to boost.fusion, or would that be a stand-alone 'module' itself dependent on both ? While I have no opinion on whether it's useful (I haven't had a chance to use boost.fusion yet), I don't think it would be acceptable to add dependencies to boost.python itself. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
What exactly to you mean by 'adding to boost.python' ? Would this add a dependency, either to boost.python or to boost.fusion, or would that be a stand-alone 'module' itself dependent on both ?
I'm talking about making this little tool available somewhere in the boost/python directory, but you can indeed see it as standalone. It will be an optional header that users can include if they need it (like the indexing suites), so not really a "dependency". Bruno
Bruno Lalande wrote:
What exactly to you mean by 'adding to boost.python' ? Would this add a dependency, either to boost.python or to boost.fusion, or would that be a stand-alone 'module' itself dependent on both ?
I'm talking about making this little tool available somewhere in the boost/python directory, but you can indeed see it as standalone. It will be an optional header that users can include if they need it (like the indexing suites), so not really a "dependency".
Yes, but it will still be a dependency for packagers that try to build modular boost packages. A potential packager who attempts to build a boost.python package will either have to make the newly generated boost.python package dependent on a boost.fusion package, or he will have to exclude this header from his boost.python package. This question is by far not specific to this particular case. On Fedora, for example, there is only a single 'boost' package, containing everything (not exactly modular, isn't it ?!). Debian provides a 'boost-python' package, but it drags in dependencies to things as tangential as 'boost-serialization' ! I don't think this is an acceptable practice, but since boost so far seems to refuse to take leadership in providing packaging guidelines (or otherwise help make boost more modular), things won't improve. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
На Fri, 27 Feb 2009 11:38:37 -0500 Stefan Seefeld <seefeld@sympatico.ca> wrote:
Yes, but it will still be a dependency for packagers that try to build modular boost packages. A potential packager who attempts to build a boost.python package will either have to make the newly generated boost.python package dependent on a boost.fusion package, or he will have to exclude this header from his boost.python package.
This question is by far not specific to this particular case. On Fedora, for example, there is only a single 'boost' package, containing everything (not exactly modular, isn't it ?!). Debian provides a 'boost-python' package, but it drags in dependencies to things as tangential as 'boost-serialization' !
What is the advantage of splitting boost in tiny pieces? I don't see much benefit in it and have no idea why Debian does that. Also, even Debian isn't braindead enough to have separate package for Boost.Fusion. It's part of libboost-dev which boost_python depends on anyway.
What is the advantage of splitting boost in tiny pieces? I don't see much benefit in it and have no idea why Debian does that. Also, even Debian isn't braindead enough to have separate package for Boost.Fusion. It's part of libboost-dev which boost_python depends on anyway.
I agree... I'm a Debian user and I'm happy in the way Boost is packaged but really, I won't be much less happy with only 2 packages, dev and runtime. Moreover Boost.Fusion is header-only so regarding the packaging rules of Debian, there wouldn't be any other dependency at package level. But anyway Stefan... are you sure this is a dependency? We know that generic programming and metaprogramming techniques allow totally foreign modules to interoperate very intimately. Great: a library author can design its stuff to be adaptable with other libraries. Problem: the adaptation can be tricky and need too much skill from the user. Solution: the library author provides the adaptation glue for the most widely used libraries. Does that make his library suddenly "depend" on them? No, it only makes it "ready for" them. So even if a highly fine-grained packaging tree was to be made, it would have to separate dependencies from adaptations, anyhow. And what I propose clearly falls into the second category. Bruno
Bruno Lalande wrote:
This looks very useful to me.
So only one person interested, not sure it's enough to integrate it :-) Dave, as you are the library author, do you think it's worth doing or not?
You might try bringing it up on the c++-sig python list, greater concentration of boost.python users over there. -t
participants (5)
-
Bruno Lalande -
John Reid -
Sergey Popov -
Stefan Seefeld -
troy d. straszheim