[C++-sig] Boost.Python and PEP 384
Do Boost.Python-generated extension modules conform to PEP 384's constraints for ABI compatibility? Thx, Skip Montanaro ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] Getting Boost.Python to explain itself better?
I'm trying to debug an assertion error from Boost.Python, but having
no luck. I'm not a C++ programmer, but to my eyes, it seems like my
call should work. I'm using Boost 1.47.0 on an openSuSE 12.2 platform,
with GCC/G++ 4.4. These parameters are fixed (that is, suggestions
that I update any of them aren't going to fly - I am tied to those
versions by factors outside my control). Here's a simple example,
which used to work:
>>> service.Provider
>>> pro = service.Provider("Skip-hacking")
>>> pro2 = service.Provider("Skip-hacking", {})
>>> pro3 = service.Provider("Skip-hacking", {}, 4001)
I'm upgrading to accommodate some internal version dependency changes
in other internal libraries, which should (in theory) have no effect
on the build and functioning of the Boost.Python wrappers, certainly
of this particular wrapper. Still, something's amiss. Here's the same
example using my new version:
>>> service.Provider
>>> pro = service.Provider("Skip-hacking")
>>> pro2 = service.Provider("Skip-hacking", {})
ArgumentError Python argument types in
Provider.__init__(Provider, str, dict)
did not match C++ signature:
__init__(boost::python::api::object, std::string,
std::map,
std::allocator > >,
int)
__init__(boost::python::api::object, std::string,
std::map,
std::allocator > >)
__init__(boost::python::api::object, std::string)
[||1]
>>> pro3 = service.Provider("Skip-hacking", {}, 4001)
ArgumentError Python argument types in
Provider.__init__(Provider, str, dict, int)
did not match C++ signature:
__init__(boost::python::api::object, std::string,
std::map,
std::allocator > >,
int)
__init__(boost::python::api::object, std::string,
std::map,
std::allocator > >)
__init__(boost::python::api::object, std::string)
[||1]
It seems that Boost.Python doesn't think my empty dictionary is
compatible with the std::map<...> type. Even if I pass a small,
populated dictionary, it barfs:
>>> pro4 = service.Provider("Skip-hacking", {"name": "skip"})
ArgumentError Python argument types in
Provider.__init__(Provider, str, dict)
did not match C++ signature:
__init__(boost::python::api::object, std::string,
std::map,
std::allocator > >,
int)
__init__(boost::python::api::object, std::string,
std::map,
std::allocator > >)
__init__(boost::python::api::object, std::string)
[||1]
The upgrade was only for version dependencies (we live in version
dependency hell at work). There were no code changes to either the
Boost.Python wrapper or the underlying C++ libraries between versions
9.4 and 9.5. In fact, this is very basic stuff in our environment
which hasn't changed functionally in several years.
I'd appreciate some insight about Boost.Python's thought processes.
Why doesn't it like my dictionaries (empty or populated)?
Thanks,
Skip
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Getting Boost.Python to explain itself better?
On Fri, Jun 17, 2016 at 8:37 AM, Skip Montanaro
wrote:
>
> >>> pro2 = service.Provider("Skip-hacking", {})
> ArgumentError Python argument types in
> Provider.__init__(Provider, str, dict)
> did not match C++ signature:
> __init__(boost::python::api::object, std::string,
> std::map,
> std::allocator > >,
> int)
> __init__(boost::python::api::object, std::string,
> std::map,
> std::allocator > >)
> __init__(boost::python::api::object, std::string)
> [||1]
After a bit more digging I think I found the problem, but am unclear
how to solve it. Down a couple levels of dependencies there is a
resource library in which a variant class is defined. It can contain
int, string or bool objects, and uses a discriminator to decide which
field is active. Kind of a union but without overlapping fields. (I
make no comment on this class. It is what it is. I just have to live
with it.) Structurally, it looks like this:
class variant {
public:
...
enum Which {
NONE = 0x00,
INT = 0x01,
STR = 0x02,
BOOL = 0x03
};
...
private:
Which which_;
int i_;
std::string s_;
bool b_;
}
Somewhere along the way, someone needed to use one of these variants
in a context where two variants needed to be compared, so a public
operator< method was added. The data layout of the class instances
didn't change. My programs were happily communicating with a server
running the newer version of the class while it still relied on the
older version.
The addition of that public operator< method is what seems to have
tripped up Boost.Python. Is there some way to convince it to accept
the version of the variant class which contains this method?
Thx,
Skip
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] Fwd: Wrapping a singleton using pybind11?
Looking around for help with pybind11, I saw a brief flurry of activity related to it here back in Oct 2015, when Wenzel Jakob introduced it. Since then, not so much. I'm trying to come up-to-speed with it, though I'm not a C++ programmer, so it's been a slow slog so far. Almost the first thing I tried to do has me stumped. I have a singleton class (no public constructor, C++ programmers call an instance() member function). As a Python programmer, that seems crude to me. In Python, I'd write a __new__ method and let programmers pretend they have different instances. We already have some Boost.Python wrappers for parts of our C++ libraries. The general strategy there seems to be to create a second struct which does have a constructor and a bunch of one-line member functions, then use .def(py::init<>()) That also seems crude, *and* makes me have to repeat myself. For every member function (static or otherwise) that I want to expose, not only do I have to add the necessary .def(...) call, I have to also add a silly member function to that artificial struct created to provide a public constructor. (And since they are structurally separate, I can't even use preprocessor macros to expand things.) Is there an straightforward way to wrap a singleton class using pybind11 which minimizes the amount of boilerplate I have to write? I thought I'd be able to figure out type converters, then write a few .def(...) calls, and be done with it. That's turning out not to be the case, at least not for me. I suppose if was an actual C++ programmer, I would be further along at this point. Thanks, Skip Montanaro ___ Cplusplus-sig mailing list Cplusplus-sig@python.org https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Compiling boost python
> How the cmake support for pybind ? I don't know cmake, but I did use pybind11 at my last job. It's nothing more than header files (no libraries to link). I doubt it would be difficult to support. Skip ___ Cplusplus-sig mailing list Cplusplus-sig@python.org https://mail.python.org/mailman/listinfo/cplusplus-sig
