Mailman 3 March 2007 - Cplusplus-sig

How to import a boost::python dll in windows?
by ichijoji Aug. 5, 2011

Aug. 5, 2011

I'm trying to port some research code that uses boost::python to expose a library to python to windows, but I'm having trouble importing the dll into python. I'm compiling using msvc 2005 and using python 2.5, but when I try to import the module I get this: Traceback (most recent call last): File "main.py", line 1, in <module> import object File "c:\code\sge\code\scripts\object.py", line 1, in <module> import sge ImportError: No module named sge My module is named sge and I'm compiling to sge.dll. Is there some obvious reason why python wouldn't be able to find my dll? When I compile on linux into an so this code works fine. -- View this message in context: http://www.nabble.com/How-to-import-a-boost%3A%3Apython-dll-in-windows--tf3… Sent from the Python - c++-sig mailing list archive at Nabble.com.

4 4

Base class defined in other header file not included in bp::bases<>
by Haridev, Meghana Sept. 14, 2008

Sept. 14, 2008

Hi Folks, I'm having some trouble generating boost-python wrapper code using pyplusplus for a derived class which has one of its base classes defined in another file. Simple scenario: mydir/ other.hpp: class baseB{ }; hierarchy.hpp: #include "other.hpp" class baseA{ }; class derivedC: public baseA, public baseB{ }; generate_code.py: import os from pyplusplus import module_builder mb = module_builder.module_builder_t( files=['hierarchy.hpp'] ) mb.build_code_creator( module_name='inherit' ) mb.code_creator.user_defined_directories.append( os.path.abspath('.') ) mb.write_module('boost_hierarchy.cpp') ------------------------------------------------------------------------ ------------------------------------------------- Generated code (boost_hierarchy.cpp) looks like this: // This file has been generated by pyplusplus. #include "boost/python.hpp" #include "hierarchy.hpp" namespace bp = boost::python; BOOST_PYTHON_MODULE(inherit){ bp::class_< baseA >( "baseA" ); bp::class_< derivedC, bp::bases< baseA > >( "derivedC" ); } How can I get pyplusplus to add 'baseB' to bp::bases<> for 'derivedC' class when 'baseB' class is defined in another file (present in the same directory or different directory)? When I move the definition of 'baseB' class to hierarchy.hpp, boost wrapper for 'derivedC' is correctly generated as: bp::class_< derivedC, bp::bases< baseA, baseB > >( "derivedC" ); Thanks, -Meghana.

3 9

'iteritems', 'iterkeys' and 'itervalues' in dict
by Nindi Singh April 11, 2008

April 11, 2008

Apolgies for not putting the subject line in my last email. In the Boost.Python dict class there are methods 'iteritems', 'iterkeys' and 'itervalues' all returning objects. How exactly are you supposed to use these objects (iterators) ? ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

2 1

C++ singleton
by Emmanuel Taurel Oct. 31, 2007

Oct. 31, 2007

Hello everybody, I am actually writing an interface to python for an existing C++ library using Boost. This library has a C++ singleton class. This class has only one constructor (with arguments) which is "protected" because it's a singleton. I am not able to build a Boost interface to this class because the compiler complains that the constructor I have given to Boost in the class_xxx constructor argument is not public (which is true) ! Therefore, my question is simple : How is it possible to interface such a class with only one constructor which is protected and a static method to create/access the object ? Thank's very much for your answer. Sincerely Emmanuel Taurel (etaurel(a)cells.es) PS : By the way, is there a searchable archive of this mailing list ?

4 3

Supplying a Python base class when wrapping a C++ class...
by Alex Mohr April 19, 2007

April 19, 2007

I'd like to wrap a C++ class and have the generated python wrapper class derive from a Python class. I know I can use bases<> to have my wrapped class derive from the class objects associated with the C++ types I specify in bases<>, but in this instance, I want to derive my wrapper class from a Python class that was not generated by boost.python. From looking at the code, it seems like it would be some work to add this capability. (Is anyone working on something like this?) As a workaround, does anyone know a way that I could perhaps hack this in after the Python class is created? That is, can I change the Python base classes of a Python class at runtime? Thanks, Alex

5 7

range with virtual functions
by Piotr Jaroszynski April 8, 2007

April 8, 2007

Hello, I have yet another "problem" :] I want to expose a begin_foo and end_foo functions as an iterable object like: .add_property("foo", range(&Blah:begin_foo, &Blah::end_foo)) How can I do it when begin_foo and end_foo are virtual functions? I am interested in both cases, when they are pure virtual and virtual with default implementation. TIA for help! -- Best Regards, Piotr Jaroszynski

3 3

std::string by reference from C++ to Python
by Francis Moreau April 7, 2007

April 7, 2007

Hi, I would like to know what is the best way to pass a std::string by reference from C++ to Python. I know this should not work directly since string are immutable in Python. Let's say that I have this C++ base class: class State { virtual bool processEvent(const Event& in_event, std::string& out_strNextState); } And this C++ base class could be derived from Python, then Python would be able to decide what is the next state by setting out_strNextState function parameter. I know this could be much easier by changing the signature of the processEvent function (as retourning a std::string), but it's important for me to keep this signature. Thanks, Francis

3 2

[Attention] BBv2 Python Build Support
by David Abrahams April 3, 2007

April 3, 2007

******************************************************************** *** The Boost release has been waiting on this; I would *really* *** *** appreciate it if people would take a little time to test it. *** ******************************************************************** I've just checked into the RC_1_34_0 branch most of the support for building and testing Python extensions and Boost.Python in BBv2. It took me over a week, and it's almost completely revamped. In case you're wondering, yes, it was necessary. Support for Windows, Darwin, and Cygwin was essentially nonexistent or broken. If it was working for you on any of these platforms, you were probably getting "lucky." I would appreciate it if those who can test this would invoke bjam with --debug-configuration, and look at the output to make sure the python configuration stuff looks sensible. Here's the new comment on python.init: # Initializes the Python toolset. Note that all parameters are # optional. # # - version -- the version of Python to use. Should be in Major.Minor # format, for example 2.3. Do not include the subminor version. # # - cmd-or-prefix: Preferably, a command that invokes a Python # interpreter. Alternatively, the installation prefix for Python # libraries and includes. If empty, will be guessed from the # version, the platform's installation patterns, and the python # executables that can be found in PATH. # # - includes: the include path to Python headers. If empty, will be # guessed. # # - libraries: the path to Python library binaries. If empty, will be # guessed. On MacOS/Darwin, you can also pass the path of the # Python framework. # # - condition: if specified, should be a set of properties that are # matched against the build configuration when Boost.Build selects a # Python configuration to use. # # Example usage: # # using python : 2.3 ; # using python : 2.3 : /usr/local/bin/python ; # You can set up your user-config.jam so a bjam built under Windows will can build/test both windows and cygwin python extensions. Just pass <target-os>cygwin in the "condition" parameter to "using python..." for the cygwin python installation. using python ; # windows installation using python : : /usr/bin/python2.5 : : : <target-os>cygwin ; when you put target-os=cygwin in your build request, it should build with the cygwin version of python: bjam target-os=cygwin toolset=gcc This is supposed to work the other way, too (targeting windows python with a cygwin bjam) but it seems as though the code in the compiler toolsets for building that way is broken (i.e., it's not a python-specific problem). What's still broken =================== 1. When targeting Cygwin, PYTHONPATH setup information is not properly passed from Python extension targets to test targets, because the information is getting attached to an import library (one we don't even need to generate) instead of the shared library. This affects one test (builtin_converters) in the Boost.Python test suite. We're waiting on Vladimir Prus to fix that one. I hope he'll be able to do that in the next few days. 2. There's no support for debug-python builds (the ones that require the trailing "_d" in the executable and extension module names -- see http://boost.org/libs/python/doc/building.html#variants). I think I can implement that tomorrow. If you got this far in the message, thank you *very* much for your attention :) -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 5

Two Boost.Python talks at BoostCon'07
by David Abrahams April 2, 2007

April 2, 2007

I'm giving a tutorial called "Hybrid Development with Boost.Python (and More!)" [http://www.boostcon.com/program/sessions#abrahams-hybrid] and Timothy Shead will be speaking on "Implementing out-of-the-ordinary object models using Boost.Python" [http://www.boostcon.com/program/sessions#shead-python-object-models] >From the site: "Promising to be the main face-to-face event for all things Boost, BoostCon'07 opens the door to your C++ future. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and from TR1 to TR2, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with Boost for the next year." see http://www.boostcon.com -- Dave Abrahams Boost Consulting www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com

2 2

[python] Fix for boost::python::import
by Stefan Seefeld March 28, 2007

March 28, 2007

The attached patch fixes the boost::python::import implementation. It used to work fine for modules already ('physically') imported into the process, but not for new ones. I'd like to apply to HEAD, and would like to ask whether it is OK for the R_1_34 branch, too. The problem is that the 'import' function is new (well, it's actually two years old, but not in any official release), and no unit test exists. Thus, part of this patch is a unit test that demonstrates the failure on the existing implementation, as well as the fix. OK to commit to HEAD and R_1_34 ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... Index: libs/python/src/import.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/python/src/import.cpp,v retrieving revision 1.2 diff -u -r1.2 import.cpp --- libs/python/src/import.cpp 27 Oct 2006 21:17:25 -0000 1.2 +++ libs/python/src/import.cpp 1 Mar 2007 02:00:47 -0000 @@ -17,7 +17,7 @@ { // should be 'char const *' but older python versions don't use 'const' yet. char *n = python::extract<char *>(name); - python::handle<> module(python::borrowed(PyImport_AddModule(n))); + python::handle<> module(python::borrowed(PyImport_ImportModule(n))); return python::object(module); } Index: libs/python/test/Jamfile.v2 =================================================================== RCS file: /cvsroot/boost/boost/libs/python/test/Jamfile.v2,v retrieving revision 1.22 diff -u -r1.22 Jamfile.v2 --- libs/python/test/Jamfile.v2 13 Oct 2006 21:33:37 -0000 1.22 +++ libs/python/test/Jamfile.v2 1 Mar 2007 02:00:48 -0000 @@ -151,6 +151,7 @@ /boost/python//boost_python ] [ bpl-test map_indexing_suite : map_indexing_suite.py map_indexing_suite_ext ] +[ py-run import_.cpp ] # if $(TEST_BIENSTMAN_NON_BUGS) # { Index: libs/python/test/import_.cpp =================================================================== RCS file: libs/python/test/import_.cpp diff -N libs/python/test/import_.cpp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ libs/python/test/import_.cpp 1 Mar 2007 02:00:48 -0000 @@ -0,0 +1,51 @@ +// Copyright Stefan Seefeld 2007. +// Distributed under the Boost Software License, Version 1.0. (See +// accompanying file LICENSE_1_0.txt or copy at +// http://www.boost.org/LICENSE_1_0.txt) + +#include <boost/python.hpp> + +#include <boost/detail/lightweight_test.hpp> +#include <iostream> + + +namespace bpl = boost::python; + +void import_test() +{ + // Retrieve the main module + bpl::object import_ = bpl::import("import_"); + int value = bpl::extract<int>(import_.attr("value")) BOOST_EXTRACT_WORKAROUND; + std::cout << value << std::endl; + BOOST_TEST(value == 42); +} + +int main(int argc, char **argv) +{ + // Initialize the interpreter + Py_Initialize(); + + if (bpl::handle_exception(import_test)) + { + if (PyErr_Occurred()) + { + BOOST_ERROR("Python Error detected"); + PyErr_Print(); + } + else + { + BOOST_ERROR("A C++ exception was thrown for which " + "there was no exception handler registered."); + } + } + + // Boost.Python doesn't support Py_Finalize yet. + // Py_Finalize(); + return boost::report_errors(); +} + +// Including this file makes sure +// that on Windows, any crashes (e.g. null pointer dereferences) invoke +// the debugger immediately, rather than being translated into structured +// exceptions that can interfere with debugging. +#include "module_tail.cpp" Index: libs/python/test/import_.py =================================================================== RCS file: libs/python/test/import_.py diff -N libs/python/test/import_.py --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ libs/python/test/import_.py 1 Mar 2007 02:00:48 -0000 @@ -0,0 +1 @@ +value = 42

4 6