Re: [C++-sig] boost::python constructing object from PyObject *
The best I could find was object(borrowed(ptr)) for new references and object(handle<>(ptr)) for borrowed pointers. I'm not sure if that is accurate, but if so that deserves a nomination for a terrible interface award. The documentation isn't great, but the name 'borrowed' is a hint. Using borrowed instructs boost.python that the PyObject * is a borrowed reference. So you can use: object(handle<>(borrowed(ptr))) for when ptr is a borrowed reference and object(handle<>(ptr)) for when ptr is a new reference. Alex ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] mutable object has bogus __hash__
I would like to have the __hash__ not exist. These objects are mutable and should NOT be used as keys. Is there a way to hide it? If I have them throw NotImplemented will python do something sensible with that? Python raises a TypeError for unhashable things: >>> [1,2,3].__hash__() Traceback (most recent call last): File "", line 1, in TypeError: list objects are unhashable (You get the same with hash([1,2,3]) of course.) Alex ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] profiling C++ python extension
I am aware that oprofile and valgrind exist. Has anyone of you ever done profiling a C or C++ extension with gprof? Not me, but I have to say that valgrind's callgrind tool with kcachegrind to view the results has been perhaps the best profiling experience I've had on Linux. I've had good success using these tools to profile C++ python extensions. Alex ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Dynamic resolution of members and methods
Override the python special methods __getattr__ or __getattribute__. http://docs.python.org/reference/datamodel.html#attribute-access Alex Jérémie Delaitre wrote: Hello, I have a C++ class that use a custom property system. This property system allows me to add and remove properties at runtime. I want to expose this class into Python. The problem is: I want "a dynamic resolution" of the properties in Python. For example: # import my python extension import myModule # get an instance of my C++ class t = myModule.newInstance() # access the property 'myProperty' print(t.myProperty) When I access the property, I want python to call a "callback" of mine (written in the C++ extension) which will check if the requested property exists, and if it does, return the corresponding value, otherwise generate an exception. By looking at the python C API, I did not find a way to achieve this. It seems that declaring a new type requires to have static arrays for members and methods (yes, my property system allows me to declare new methods too, so I want to expose them with a similar system). Any idea how I could resolve this (with Python3.0) ? Regards, Jérémie Delaitre ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Getting object for PyObject (reference counting)
Murray Cumming wrote: I can't find any definitive documentation that tells me how I should get a boost::python::object to wrap an existing PyObject*. I guess that there's a way to do it that uses an existing reference, and a way that takes an extra reference. You can construct a boost::python::object with a boost::python::handle<>. boost::python::handle<> is sort of a "smart" PyObject *. It manages the python object reference count automatically. When you create a boost::python::handle<> you can tell it whether to bump the reference count or not. Given a PyObject *p: // Use with a "new reference" -- *doesn't* bump ref count. handle<>(p); // Use with a "borrowed reference" -- *does* bump ref count. handle<>(borrowed(p)); Alex ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Getting object for PyObject (reference counting)
Oh, I assumed that boost::python::object did this already.
It does. Think of bp::handle<> as a low-level, bare-bones, smart
PyObject*. Think of bp::object as that, *plus* all the fancy c++ API
that maps to python API (like obj.attr("foo"), []-operator, ()-operator,
etc).
I believe bp::object holds a handle<> internally.
If not, is there any reason not to use
boost::python::handle everywhere instead of a
boost::python::object?
Don't do that. You can't do that. It won't compile. Use bp::object
everywhere unless you're convinced you have a good reason to do
otherwise. If you have a PyObject *p and you want a bp::object,
construct it via:
object(handle<>(p)) // when p's a new reference
object(handle<>(borrowed(p))) // when p's a borrowed reference
One of my main reasons for using boost::python instead of the C API is
to avoid worrying so much about the reference counting. For instance, I
don't want to explicitly increment the ref when returning a PyObject, or
remember whether I should take a ref when given a PyObject from various
functions.
Yup. Just use bp::object everywhere. I recommend you read through the
reference manual:
http://www.boost.org/doc/libs/1_38_0/libs/python/doc/v2/object.html
http://www.boost.org/doc/libs/1_38_0/libs/python/doc/v2/handle.html
Also look at the tutorials and examples and tests in the boost.python
distribution.
Alex
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Boost Python objects and object identity
Renato Araujo wrote:
I had the same problem as you in my binding implementation, then I
solve the problem using this function:
//
// a generator with an execute() function which, given a source type
// and a pointer to an object of that type, returns its most-derived
// /reachable/ type identifier and object pointer.
//
// first, the case where T has virtual functions
template
struct polymorphic_id_generator
{
static dynamic_id_t execute(void* p_)
{
T* p = static_cast(p_);
return std::make_pair(dynamic_cast(p), class_id(typeid(*p)));
}
};
I use this function to get a pointer to most-derived type and use this
as key in my hash table.
Cool -- how do you clean the table when an object is destroyed?
Alex
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Catching Boost.Python.ArgumentError
On 4/26/2010 1:22 AM, Austin Bingham wrote: I feel like I'm missing something simple, but how do I catch Boost.Python.ArgumentException? As far as I can tell, the Boost.Python module is not something I can import explicitly, so I can't write "catch Boost.Python.ArgumentException:". I can do something like comparing type and module name strings, but that just feels inelegant and a trouble for maintenance. Any ideas would be very welcome. I haven't looked at the code in awhile but I think I do it by intentionally generating an ArgumentError, catching it, and in the handler where I have the exception object, I store its class away for later use. Alex ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [boost.python] Can't import a wrapped template class
On 10/26/2012 11:16 AM, Paul O. Seidon wrote: would do that. Should I try dont_care = _Variable(); in main.cpp? Looks a bit strange, but would force the compiler to generate code for sure. You either need to inline the ctor in the header or do an explicit instantiation of _Variable somewhere. I suggest you read up on "explicit instantiation" and c++ templates in general. This problem isn't related to boost.python. Alex ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [boost.python] Can't import a wrapped template class
On 10/26/2012 1:27 PM, Stefan Seefeld wrote: The entire issue disappears if you move your member function definitions (including the constructor) from varbls.cpp to varbls.h. Alternatively, explicitly instantiate in varbls.cpp. template class _Variable; Again, you might want to google "explicit template instantiation" or similar. Alex ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] Segfault with keyword arguments and overloads.
I'm hitting a repeatable segfault trying to upgrade our boost version.
I believe there may be a bug with overload resolution in the presence of
keyword arguments. Here's a minimal example that crashes for me.
// C++
#include
static void f1(int a0, int a1) { }
static void f2(int a0, int a1, int a2) { }
BOOST_PYTHON_MODULE(kwargCrash) {
boost::python::def("f", f1, (arg("a1")=2));
boost::python::def("f", f2, (arg("a2")=2));
}
# Python
import kwargCrash
kwargCrash.f(0, a1=2)
Version info: boost 1.51.0, Python 2.7.5, gcc 4.8.1.
In the example we pass one positional argument and one keyword argument.
This should fail to match the second overload (f2) since two
positional arguments are required, and should match and invoke the first
(f1). Instead, it segfaults.
Here's my hypothesis as to what's happening from inspecting the
boost.python code:
In libs/python/src/object/function.cpp, function::call() (line 123)
- We consider overloads in reverse reg order, so we try 'f2' first.
- We pass the if on line 138, since n_actual is 2,
f->m_nkeyword_values is 1, and min/max_arity==3.
- The if on line 144 passes, since kwargs were supplied.
- The fn has kwargs, so we take the 'else' on line 152.
- We reach the 'build a new arg tuple...' else clause on line 167.
- We make a tuple of size 3 and set the first element with the
positional arg '0'.
- Now we loop arg_pos = 1 to max_arity-1 (line 180).
- Line 183, we set: kv = PyTuple_GET_ITEM(f->m_arg_names, arg_pos).
- Line 189, we do: PyTuple_GET_ITEM(kv, 0).
In this case, I believe kv is actually None, not a tuple, which gives us
a bogus result, and I crash in the PyDict_GetItem call. Here's why I
believe kv is actually None:
In function.cpp again, function ctor (line 67)
- Consider when an instance is created for 'f2'.
- Line 72: keyword_offset gets set to 2 (max_arity = 3, num_keywords
= 1).
- m_arg_names is created with size 3 (max_arity)
- Line 80: loop and set the first 2 elements (keyword_offset) to None.
So the leading elements of the tuple get set to None, until we actually
have keywords -- those elements get set to pairs of kwarg-name, kwarg-value.
If my inspection is valid, then the indexing logic in function::call is
busted. It assumes that it always gets a tuple of name/value for kv if
it gets to line 189. But in this case it gets None since the argument
at index 1 has no keyword.
Does this sound plausible? I'm a bit surprised this was working for us
previously, as the code looks like it hasn't really changed. Maybe we
were getting lucky and Python changed in a way that breaks us? I.e.
maybe PyTuple_GET_ITEM actually gave None if kv was None, and we never
had None as a key in the passed keywords dict.
Assuming my hypothesis is true, I'm not sure what the right fix here is
off the top of my head. Naively it seems like checking for None in
m_arg_names and rejecting the overload might work, but it feels like the
right thing to do is to rework the logic used to decide whether or not a
call has a satisfactory combination of positional and keyword args.
Any thoughts appreciated.
Alex
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Segfault with keyword arguments and overloads.
Thanks for your response. I've responded to your comments in-line below. After further investigation, I believe this can be fixed by simply checking for None when we get 'kv' from f->m_arg_names while resolving keywords. If we encounter None, that means the overload doesn't accept a keyword argument in that position (so not enough positional args were passed), and we can reject the overload. If it works, I think that's a simple, targeted fix that isn't particularly risky. I'll try to work up a patch. On 8/7/2013 3:21 AM, Alex Leach wrote: I think the signature looks incorrect here. From my understanding of signatures, if you define one argument name, you should define the name for all arguments. On class methods, this includes adding an arg for 'self'. That makes sense if I was interested in the auto-docstring generation, but I'm not: in fact we don't use it. Reading the docs for boost::python::def, and boost::python::class_<>::def, it seems like trailing keyword arguments are supported: http://www.boost.org/doc/libs/1_54_0/libs/python/doc/v2/def.html#def-spec http://www.boost.org/doc/libs/1_54_0/libs/python/doc/v2/class.html#class_-spec In particular, "If the longest valid prefix of A1 contains N types and a1 holds M keywords, an initial sequence of the keywords are used for all but the first N - M arguments of each overload." Moreover, it would surprise me if boost.python demanded that if you want any argument to be a keyword argument then *all* arguments must be keyword arguments, and the code appears to be written to allow a mixture of positional and keyword arguments. Also, it seems strange that you're assigning the final argument a default value, when the actual C++ function has none. I did add the corresponding default argument to the C++ function signatures, but that still seg faults, so I guess you've got default arguments in your actual code (good minimal example, though!). However, the function signature in the documentation - ie. from `help(kwargCrash)` - looks correct. I could have added default args to the C++ functions, but they'd never be used and thus seemed superfluous so I left them out. And yes, thanks, providing keyword arguments for all arguments does workaround the crash, but it's not a very practical option for me, since I have at least tens of thousands of lines of boost.python wrapping code to deal with. It would be nice to just fix the crash bug and have this use-case work correctly. Alex ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Segfault with keyword arguments and overloads.
Oh! I did miss your patch, sorry. Thanks!
It looks to me like your patch calls PyTuple_GET_ITEM() with None as the
python object (when kv is None). The python docs for PyTuple_GET_ITEM
say, "Like PyTuple_GetItem(), but does no checking of its arguments."
To me that means that the object you pass really needs to be a tuple.
Here's the patch I'm using -- it simply checks to see if kv is None,
which is true if the overload doesn't accept a keyword arg in that
position, and if so it simply rejects the overload. This is working for
me in the example and across our codebase and testsuite.
I will file a bug as you suggest, and thanks again.
Alex
--- ./boost_1_53_0/libs/python/src/object/function.cpp.orig 2013-07-22
17:38:54.0 -0700
+++ ./boost_1_53_0/libs/python/src/object/function.cpp 2013-08-07
10:25:26.963988000 -0700
@@ -182,6 +182,16 @@
// Get the keyword[, value pair] corresponding
PyObject* kv =
PyTuple_GET_ITEM(f->m_arg_names.ptr(), arg_pos);
+// If kv is None, this overload does not
accept a
+// keyword argument in this position,
meaning that
+// the caller did not supply enough positional
+// arguments. Reject the overload.
+if (kv == Py_None) {
+PyErr_Clear();
+inner_args = handle<>();
+break;
+}
+
// If there were any keyword arguments,
// look up the one we need for this
// argument position
On 8/8/2013 2:28 AM, Alex Leach wrote:
Hi Alex,
On Wed, 07 Aug 2013 18:06:24 +0100, Alex Mohr wrote:
Thanks for your response. I've responded to your comments in-line below.
After further investigation, I believe this can be fixed by simply
checking for None when we get 'kv' from f->m_arg_names while resolving
keywords. If we encounter None, that means the overload doesn't
accept a keyword argument in that position (so not enough positional
args were passed), and we can reject the overload.
If it works, I think that's a simple, targeted fix that isn't
particularly risky. I'll try to work up a patch.
Sounds like you missed it, but I did add a fairly simple patch to my
previous email. I used your code as a test case and it worked fine; no
seg faults. I've copied it again below...
I don't have commit privileges to Boost Python, but I think from your
explanations, that this is a valid bug in BP. So it would probably be
worthwhile filing a bug report, at
http://www.boost.org/development/bugs.html
Unless someone with commit privileges wants to consider merging it? My
only thought on the patch regards return value optimisation. Would
moving the `PyObject *` declarations out of the loop impair the
compiler's ability to perform RVO?
Hope that helps anyway.
Kind regards,
Alex
--- ./boost_1_53_0/libs/python/src/object/function.cpp.orig
2013-08-07 11:02:28.569236835 +0100
+++ ./boost_1_53_0/libs/python/src/object/function.cpp 2013-08-07
11:56:10.926045853 +0100
@@ -177,16 +177,18 @@
// Grab remaining arguments by name from the
keyword dictionary
std::size_t n_actual_processed =
n_unnamed_actual;
+PyObject *kv, *k, *value;
for (std::size_t arg_pos = n_unnamed_actual;
arg_pos < max_arity ; ++arg_pos)
{
// Get the keyword[, value pair]
corresponding
-PyObject* kv =
PyTuple_GET_ITEM(f->m_arg_names.ptr(), arg_pos);
+kv = PyTuple_GET_ITEM(f->m_arg_names.ptr(),
arg_pos);
// If there were any keyword arguments,
// look up the one we need for this
// argument position
-PyObject* value = n_keyword_actual
-? PyDict_GetItem(keywords,
PyTuple_GET_ITEM(kv, 0))
+k = PyTuple_GET_ITEM(kv, 0);
+value = (k != NULL && n_keyword_actual)
+? PyDict_GetItem(keywords, k)
: 0;
if (!value)
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Bugs in the Boost.Python tutorial example
On 11/17/2014 2:01 PM, Stefan Seefeld wrote: (Specifically: I'd be happy to help fix issues with the Boost.Python code itself, but I don't feel competent with bjam / Boost.Build, and my knowledge of MSVC is almost non-existent, not to speak of the fact that I have no computer near me running Windows, so I couldn't even test any Windows-specific patches.) Thanks for offering! Here's a report for a crash bug with a patch that I filed 16 months ago. The formatting is busted in the original report; please see the first comment for a properly formatted test case and patch. https://svn.boost.org/trac/boost/ticket/8978 We've been running this patch successfully since that ticket was filed. Alex ___ Cplusplus-sig mailing list [email protected] https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Bugs in the Boost.Python tutorial example
On 11/17/2014 4:17 PM, Stefan Seefeld wrote:
On 17/11/14 06:54 PM, Alex Mohr wrote:
On 11/17/2014 2:01 PM, Stefan Seefeld wrote:
(Specifically: I'd be happy to help fix issues with the Boost.Python
code itself, but I don't feel competent with bjam / Boost.Build, and my
knowledge of MSVC is almost non-existent, not to speak of the fact that
I have no computer near me running Windows, so I couldn't even test any
Windows-specific patches.)
Thanks for offering! Here's a report for a crash bug with a patch
that I filed 16 months ago. The formatting is busted in the original
report; please see the first comment for a properly formatted test
case and patch.
https://svn.boost.org/trac/boost/ticket/8978
We've been running this patch successfully since that ticket was filed.
While the issue looks clear (and the patch good), can you attach a test
case that would allow me to reproduce the issue (and observe the fix
with the patch applied) ?
Minimal test cases always accelerate the processing of reported issues. :-)
Sorry, the minimal test case is included in the report. I will inline
it here also.
Alex
// C++
#include
static void f1(int a0, int a1) { }
static void f2(int a0, int a1, int a2) { }
BOOST_PYTHON_MODULE(kwargCrash) {
boost::python::def("f", f1, (arg("a1")=2));
boost::python::def("f", f2, (arg("a2")=2));
}
# Python
import kwargCrash
kwargCrash.f(0, a1=2)
___
Cplusplus-sig mailing list
[email protected]
https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Bugs in the Boost.Python tutorial example
On 11/17/14 4:17 PM, Stefan Seefeld wrote: While the issue looks clear (and the patch good), can you attach a test case that would allow me to reproduce the issue (and observe the fix with the patch applied) ? Minimal test cases always accelerate the processing of reported issues. :-) Also please refer to this message detailing my analysis of the problem with the minimal test case: https://mail.python.org/pipermail/cplusplus-sig/2013-August/017012.html Thanks again! Alex ___ Cplusplus-sig mailing list [email protected] https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Weird function call results
On 12/19/14 5:34 AM, Stefan Seefeld wrote:
But if I declare the function f in reversed order:
BOOST_PYTHON_MODULE(test)
{
def("f", f_double);
def("f", f_int);
}
I will see "invoked f(int n = 5)" when I call f(5) and "invoked f(double d =
3.14)" when I call f(3.14) as it has to be. Why does it happen? Why does it
depend on declaration order?
It definitely shouldn't. If it does, please submit a bug report
including the test, as well as details as to what compiler and OS you
were observing the error on.
It's not a bug, it's as designed. Boost.python tries function overloads
in reverse registration order and picks the first one that works, in the
sense that all the arguments convert.
Alex
___
Cplusplus-sig mailing list
[email protected]
https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Weird function call results
On 12/26/14 2:12 AM, ilias wrote: It's not a bug, it's as designed. Boost.python tries function overloads in reverse registration order and picks the first one that works, in the sense that all the arguments convert. Is that behavior specified somewhere in the documentation? I'm not sure it is. It ought to be. It is mentioned on the TODO page where it discusses changing this behavior. http://www.boost.org/doc/libs/1_57_0/libs/python/todo.html#best-match-overload-resolution If the behavior was changed it would surely break existing code. The current behavior is at least straightforward to reason about, and we've been able to get most cases to work (even tricky ones) by carefully arranging the registration order. For the rare case where a single order doesn't work, we simply write a lightweight wrapper that takes boost::python::object args and do the introspection and dispatch manually. Sometimes we have this generic overload as a "fallback" that we register first, letting boost.python handle the simple cases when it can. Alex ___ Cplusplus-sig mailing list [email protected] https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] C++ copy construction and Python object copies
On 5/29/2015 7:28 AM, Stefan Seefeld wrote: Python's copy module allows for objects to be copied. The protocol for this will look up special method __copy__. It seems to me that this would trivially work for C++ objects providing a copy-constructor. However, the copy-constructor isn't automatically bound to __copy__. While I can certainly add that in user-code, I wonder why this isn't done by Boost.Python itself. Does anyone know the reasons for this ? Would it seem useful to add that feature ? The __copy__ method's intended semantics are to produce a "shallow" copy while the __deepcopy__ method is meant to produce a "deep" copy. Given a C++ class with a copy ctor, it's hard to know which is more appropriate. For instance, copying a shared_ptr is like a "shallow" copy but copying a vector> is like a deep copy. On the other hand copying a vector> is more like a shallow copy. I wouldn't mind an opt-in convenience utility that adds a __copy__ or __deepcopy__ method, but given the semantic subtlety, I think trying to do it automatically is dicey. Also, adding a feature to do it automatically could potentially interfere with existing binding code that manually provides __copy__/__deepcopy__ methods. Alex ___ Cplusplus-sig mailing list [email protected] https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] express pointer ownership
On 8/13/2015 4:26 AM, MM wrote: What I want to express is: The t returned by the python function should refer to object T held in c++ memory, and for instance del t should not delete the actual T object in c++ memory Should I still use "return_internal_reference" ? You can use reference_existing_object (http://www.boost.org/doc/libs/1_59_0/libs/python/doc/v2/reference_existing_object.html) But as the docs say, that can be dangerous since if I do 't = get_T()' in python and then sometime later C++ deletes the object that t refers to, now I have a dangling pointer. If I try to use 't' in python now I have undefined behavior (and likely crash). Alex ___ Cplusplus-sig mailing list [email protected] https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] virtual functions with default implementation
On 8/17/2015 11:39 AM, Stefan Seefeld wrote:
For the case with default implementation, the tutorial gives this wrapper:
struct BaseWrap : Base, bpl::wrapper
{
virtual std::string func() const
{
if (bpl::override f = this->get_override("func"))
return f();
else
return Base::func();
}
std::string default_func() const { return this->Base::func();}
};
and it seems to me much more natural to implement the "default" case
directly in the "else" branch above, rather than add it to the "def()" call.
I think this might be so that python can invoke the superclass (C++)
implementation directly in its override, but I'm not 100% sure.
Alex
___
Cplusplus-sig mailing list
[email protected]
https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] C++ comments to docstrings
Hi Andy, We do something very similar to what you describe, except we use doxygen (www.doxygen.org) to output XML files that we use to generate __doc__ strings for our python bindings. We're primarily a linux shop. I don't know how hard it would be to switch to doxygen, maybe it can deal with C#-ish style comments? But I believe it runs on Linux and Windows so perhaps it might help? Alex On 11/17/2015 1:17 PM, Andy Falanga (afalanga) wrote: Hello, My team produces a C++ library exported to python via Boost.Python. We've documented our functions and classes with C#-ish style comments. These are parse-able by Visual Studio and XML files are built from them. When our shared object file is imported in python, a function opens these files and makes the association of the appropriate "docstring" in the XML file with the __doc__ property at runtime. Now that you know how we do it currently, I'd like to know are there better methods in use by, or known to, those in this list? The main hurdle to overcome at this point is that our library is built for both Windows and Linux. Because the documentation method has been to use Visual Studio to build the XML, the Windows build must be done first and the XML left in some place that the Linux build can reach. I'd like to eliminate this dependency for Linux. Andy ___ Cplusplus-sig mailing list [email protected] https://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list [email protected] https://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Boost.Python NumPy extension
Cool! Sorry, I don't have the expertise to help with the boost.build aspect, but I did have some questions and comments regarding the feature. Does this add a dependency of boost.python on numpy? We'd love to be able to continue use boost.python without a numpy dependency. We did a nontrivial amount of work to remove this dependency in USD (openusd.org, https://github.com/PixarAnimationStudios/USD), a C++ library that provides python bindings via boost.python, so adding it back would be a problem for us. Instead of depending on numpy, we made our array structures implement the python buffer protocol. This lets clients that wish to use numpy do so easily, since numpy supports the buffer protocol, but it does not burden those that don't with the numpy dependency. We did this manually of course but supporting the buffer protocol would be a cool feature for boost.python. Alex On 10/8/16 9:21 PM, Stefan Seefeld wrote: Hello, I'm happy to announce that I just merged the NumPy C++ wrappers from https://github.com/ndarray/Boost.NumPy into Boost.Python's development branch. (Online documentation for it can be browsed here: http://boostorg.github.io/python/develop/doc/html/numpy) I'd very much like to be able to merge this into the master branch for the next Boost release (version 1.63). At present I'm using SCons to build Boost.Python (stand-alone, against a separately installed Boost), which is also the infrastructure I use for CI testing (https://travis-ci.org/boostorg/python). I would like to ask for help with integrating the new NumPy extension into the Boost.Build-based build system, such that this will also be picked up by the regular Boost infrastructure. Please refer to https://github.com/boostorg/python/issues/89 if you'd like to help with this. Many thanks ! Stefan ___ Cplusplus-sig mailing list [email protected] https://mail.python.org/mailman/listinfo/cplusplus-sig
