Mailman 3 April 2003 - Cplusplus-sig

Threads and Boost.Python
by Patrick Hartling June 15, 2003

June 15, 2003

I was able to sort out the multi-threading issues I was having earlier this week with Boost.Python thanks to David Abrahams' suggestions. What I came up with is a relatively simple guard object that is instantiated whenever C++ code calls into the Python interpreter. To make this guard work, I had to deal with two key issues: 1. Ensuring that threads created by C/C++ bootstrapped themselves with the Python interpreter. 2. Preventing deadlocks if the same thread tried to acquire the GIL more than once. Issue #1 was straightforward enough to handle. The C++ code base that I am exposing to Python includes a cross-platform data structure for thread-specific data (TSD). Within the guard, there is a static data member that is an instance of this TSD structure. Our TSD handler is a templated type, and the struct I gave it contained two fields: struct State { State() : isLocked(false), pyState(NULL) {} bool isLocked; PyThreadState* pyState; }; The boolean field is used to deal with Issue #2 from above; the thread state object needs to be different for each unique thread calling into the Python interpreter. The nice thing about our TSD handler is that a new instance of the above structure will be instantiated automatically for each thread, so whenever a new thread creates an instance of the guard, the guard constructor handles filling in the State instance fields. The code from my guard constructor is this: Guard::Guard() : mMyLock(false) { if ( NULL == mState->pyState ) { mState->pyState = PyThreadState_New(PyInterpreterState_New()); } if ( ! mState->isLocked ) { // Acquire the GIL. PyEval_AcquireThread(mState->pyState); mState->isLocked = true; mMyLock = true; } } Here, Guard::mState is the static data member that is an instance of our TSD handler. The destructor is this: Guard::~Guard() { if ( mMyLock && mState->isLocked ) { // Release the GIL. PyEval_ReleaseThread(mState->pyState); mState->isLocked = false; } } The last detail is the data member Guard::mMyLock. That is a boolean to handle keep track of which guard instance actually acquired the GIL so that it is the one to release it upon destruction. Dealing with the recursive lock problem was probably the trickiest part. It's too bad that the GIL cannot be locked twice by the same thread, but perhaps that behavior doesn't exist for all the threading implementations upon which the Python interpreter runs. On the whole, this guard concept is working very well for me, though I haven't even been using it for 48 hours yet. Conceptually, I think something like a "synchronized call" (to steal a Java concept) in Boost.Python would help automate this process. At this time, however, I don't know how well my guard will apply to arbitrary calls into the Python interpreter from a thread. It works like a charm for boost::python::call_method<>(), and that's what I care about the most right now. Two side issues I ran into involved deciding when to call PyEval_InitThreads() and where to put the two macros for allowing and disallowing threads. With the way our software works, the main thread basically doesn't do anything once it starts a microkernel's control thread. The primordial thread just sits and blocks on a semaphore waiting for the microkernel to shut down. From there on, all calls into the Python interpreter from C++ are guaranteed to come from a thread other than the one that started the interpreter. So, I put Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS in a wrapper function that is exposed to Python where the Python "main" function makes the sempahore wait call. There will be other cases I'll have to hunt down as we expand our use of Boost.Python, but at least I have the general idea of what to watch out for. -Patrick -- Patrick L. Hartling | Research Assistant, VRAC patrick(a)vrac.iastate.edu | 2624 Howe Hall: 1.515.294.4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/

2 3

Redesign for to_python/from_python converters
by David Abrahams May 21, 2003

May 21, 2003

Some background for this thread is in the following messages: http://article.gmane.org/gmane.comp.python.c++/638 describes the global Boost.Python to/from-python converter registry which associates conversion code with the C++ type(s) being converted. On re-reading this message, I realize it's confusingly worded. Don't be discouraged if it doesn't all sink in. The point is that when a function accepting a C++ argument of type Foo is wrapped, it needs a procedure to extract a Foo from the Python object. The registry associates the code for that procedure with the type Foo. http://article.gmane.org/gmane.comp.python.c++/2044 describes a proposed scheme for dealing with the fact that currently, any given C++ type can have only one to-python conversion in the global registry. This is a problem because one module may use class_<vector<string> >, while another one registers a custom conversion from vector<string> to a Python tuple of strings. http://article.gmane.org/gmane.comp.python.c%2B%2B/2161 describes the general procedure for defining an rvalue from_python converter, and shows why I haven't yet documented how to make user-defined conversions: it's just too hairy a procedure in v2 at the moment. The purpose of this thread is to discuss the design of a new interface for users to interact with to/from-python converters. First, I'd like to discuss some things which I think are desirable. It would be worth knowing which of these are important to the community: 1. Users should have the option to say that certain to/from-python converters shall only have a local effect in a single extension module. 2. It should be possible to optimize away the cost of registry lookups in some cases where it is known that the conversion is defined in the local extension module. This is a completely separate issue from #1. We can have either one without the other. 3. It should be easy for users to explicitly define new conversions. Let's deal with #3 first. You might ask, "what was wrong with the old Boost.Python v1 approach? It sure was simple!" PyObject* to_python(SomeUDT const& x) { ... } SomeUDT from_python(PyObject* p, boost::type<SomeUDT>) { ... } It was simple, but it was basically not legal C++. It worked in so many places because it exploited a very common (and somewhat subtle) bug in C++ compilers, but when if you tried to use more conforming compilers (e.g. CodeWarrior >= 8 or recent EDGs), it would fail to compile. The reasons have to do with the rules for looking up these functions from within templates. Such a scheme can be made to work legally, but you have to resort to weird tricks like asking users to define all their converters before #including Boost.Python headers or adding dummy arguments to the functions for the sake of argument-dependent lookup. There is another problem with the v1 scheme. In particular, it was an important design goal of Boost.Python v2 to eliminate the use of C++ exceptions as part of the process of resolving overloaded C++ functions (in v1, we would throw a special exception to indicate a Python argument couldn't be converted to the corresponding C++ argument type). That means that from_python conversion has to be a 2-phase process: first, determine whether a conversion is possible, then if all arguments can be converted, do all the conversions and call the C++ function. Any user-defined from_python conversion needs to be able to report convertibility separately from actually doing the conversion. There were also some ways in which the v1 interface was hard to use: the 2nd argument to the from_python converter had to exactly match the argument type to any C++ functions being wrapped, so you might need: SomeUDT from_python(PyObject* p, boost::type<SomeUDT>) { ... } SomeUDT& from_python(PyObject* p, boost::type<SomeUDT&>) { ... } SomeUDT const& from_python(PyObject* p, boost::type<SomeUDT const&>) { ... } SomeUDT* from_python(PyObject* p, boost::type<SomeUDT*>) { ... } SomeUDT const* from_python(PyObject* p, boost::type<SomeUDT const*>) { ... } and a few others. So what should the interface look like? Let's first examine the constraints that the C++ language imposes. User-defined converters can be viewed as behavioral customizations of templates in the Boost.Python library. We basically have two approaches available to us for customizing behaviors: 1. Runtime dispatching through virtual functions or function pointers. This is the approach currently taken in Boost.Python v2 for most converters. The converter registry contains pointer to functions which implement the conversions. Some runtime dispatching is always needed for cross-module conversion support, unless you want to repeat the conversion code in every module which needs it (and nobody wants that). There are other reasons to do this having to do with the way dynamic_cast and RTTI are implemented in most compilers. 2. Compile-time customization. This was the default approach in Boost.Python v1: the compiler would look up the appropriate to_/from_python function and insert a call in the function wrapper. It could even be completely inlined. The disadvantage of this approach is that it is heaviliy dependent on code visibility: the customizations have to be visible in every place that wants to take advantage of them. Boost.Python v2 uses compile-time customization only for to-python conversions of "builtin" C++ types for which there can be only one reasonable Python interpretation. For example, const char* and std::string both are converted to Python strings. Ideally, the user could select compile-time customization for to_python conversion of selected types, and additionally choose to export their converters (e.g. to the global registry). I'm really unsure about the value of compile-time customization of from_python converters. The biggest problem with it is that it limits the whole extension module to *one* conversion method for a given C++ type. Normally, a from_python converter is used to convert one Python type to a given C++ type. If another extension module has exported conversions for other Python types to the same C++ type, do you want to be able use them? There are basically two viable techniques for compile-time customization in C++: defining functions to be found by argument-dependent lookup, and template specialization. For various reasons I won't bore you with, I feel that template specialization is the only recourse for Boost.Python. I'll begin discussion of some possible interfaces in a follow-on message. -- David Abrahams dave(a)boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution

2 15

passing Numeric arrays as arguments
by Greg Landrum May 19, 2003

May 19, 2003

[Boost 1.29, python 2.2.2, g++ 3.2, RH8.0] I've been trying to get a Numeric array object passed in as an argument to a function I've defined in a BPLv2 module, without much success. At the moment I'm happy to get the object in as a PyArrayObject *, because I've got a bunch of code that is expecting those pointers. Since I can't figure out how to extract a PyArrayObject * from a python::numeric::array (if that's even possible), I've attempted to define the following simple function: PyObject *MatFunc(PyArrayObject *arg){ PyObject *res = PyTuple_New(2); return res; } (eventually this will do more, I'm starting small) but whenever I call this Python with a Numeric array as an argument, I get the dreaded catch-all "TypeError: bad argument type for built-in operation". Am I wrong to be even attempting this? Should I just give up and do a normal extension module? -greg ---- greg Landrum (greglandrum(a)earthlink.net) Software Carpenter/Computational Chemist

11 27

Ownership question.
by tALSit de CoD May 4, 2003

May 4, 2003

I have a class method that takes ownership of the object passed into it, and I want to know, how do I let boost.python know about this and not to manage that object anymore? Should i do a kludge job like make a function that return a new object, but telling boost.python not to manage it, then, when I add it into the method, it's "disappeared" from boost.python? Original thing: class cAnimCurveKey { /* stuff */ } class cAnimCurve { void addKey (cAnimCurveKey * key); // takes ownership of the key } When i wrap that in boost.python, and i create a key and then add it to the animation curve: >>> aninCurve = cAnimCurve () >>> key = cAninCurveKey () >>> animCurve.addKey (key) What happens there?? Is python the owner of the object key? I was thinking of this hack: (In C++ / boost.python) cAnimCurveKey * newAnimCurveKey () { return new cAnimCurveKey (); } BOOST_PYTHON_MODULE (kikura) { def ("newAnimCurveKey", newAnimCurveKey, return_value_policy <reference_existing_object> ()); } And that way, python is not in charge of that object, and in theory, every key that gets created, is created to be put in an AnimCurve, so it's not _that_ bad, is it? OOOOORRRRRR Is there a way to specify to boost.python that you don't want it to manage or track that object anymore? Thanks folks Cheers! tALSit de CoD | talsit.org

3 6

converting objects to python..
by Dominique Devriese May 2, 2003

May 2, 2003

Hi, I have been looking at this for some time, and I can't seem to find it. Maybe someone here can help ? (I'm using Boost.python to export the api of an app that i want to embed python in.. ( http://edu.kde.org/kig in case someone is interested ) ) I'm trying to call a python function from C++ code with some arguments. The arguments are of type "const ObjectImp*", where ObjectImp is the abstract base class of a whole lot of other types. All of them are properly wrapped, and I have tested the wrapping in different situations, and it works. The problem is that I can't seem to find how to convert a "const ObjectImp*" to a PyObject. I tried: const ObjectImp* the_object_imp_pointer; object o( the_object_imp_pointer ); use( o.ptr() ); object o2( *the_object_imp_pointer ); use( o2.ptr() ); ( and a whole lot of other things that would only make me look stupid here, so i'll omit those ;) ) In both cases, the object constructor throws an error_already_set exception, and from the debugging in boost.python internals I've done, it appears that this happens because the lib doesn't have a converter registered for the types. I thought about trying to write a converter myself, but then I thought that this would be stupid, since I wouldn't know how to do this, unless i found out how boost.python PyObject's work, and it seemed more intelligent to just ask here first ;) At one point, I also thought that the problem would be that i should first downcast the pointers to their "real" type, and try to convert that, but then I thought that would not be the case, since you're using typeid() in the conversion stuff, and that only takes into account the "real" type, not the formal type, so downcasting is not necessary.. Anyway, I'm kinda stuck on this.. Could you give me some pointers on where to look ? thanks domi -- You have been selected for a secret mission.

2 3

pyste and masking interfaces
by Sameer Agarwal April 30, 2003

April 30, 2003

hi, given my recent experiments with pyste, I was wondering if it would make sense to generalize the exclude functionality in pyste. Perhaps a userdefined callback can be defined which the wrapper generator calls before deciding to wrap a function. The callback gets as input the definition or some parsed form of it to make the decision. sameer

2 3

boost.python project files for vs.net
by Paul F. Kunz April 30, 2003

April 30, 2003

In case anybody is interested, enclosed are project files to build Boost.Python with Visual Studio .NET. I had trouble with bjam, so I use vs.net. It converted the project files for MSVC 6 to these. I fixed the path to Python in them. The boost_python.sln file... -- Microsoft Visual Studio Solution File, Format Version 7.00 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "boost_python", "boost_python.vcproj", "{E858B6C2-7DB3-4AC0-B9DB-90377118B100}" EndProject Global GlobalSection(SolutionConfiguration) = preSolution ConfigName.0 = Debug ConfigName.1 = Release EndGlobalSection GlobalSection(ProjectDependencies) = postSolution EndGlobalSection GlobalSection(ProjectConfiguration) = postSolution {E858B6C2-7DB3-4AC0-B9DB-90377118B100}.Debug.ActiveCfg = Debug|Win32 {E858B6C2-7DB3-4AC0-B9DB-90377118B100}.Debug.Build.0 = Debug|Win32 {E858B6C2-7DB3-4AC0-B9DB-90377118B100}.Release.ActiveCfg = Release|Win32 {E858B6C2-7DB3-4AC0-B9DB-90377118B100}.Release.Build.0 = Release|Win32 EndGlobalSection GlobalSection(ExtensibilityGlobals) = postSolution EndGlobalSection GlobalSection(ExtensibilityAddIns) = postSolution EndGlobalSection EndGlobal --- The boost_python.vcproj file ... --- <?xml version="1.0" encoding = "Windows-1252"?> <VisualStudioProject ProjectType="Visual C++" Version="7.00" Name="boost_python" SccProjectName="" SccLocalPath=""> <Platforms> <Platform Name="Win32"/> </Platforms> <Configurations> <Configuration Name="Release|Win32" OutputDirectory=".\../bin-stage" IntermediateDirectory=".\release-obj" ConfigurationType="2" UseOfMFC="0" ATLMinimizesCRunTimeLibraryUsage="FALSE" CharacterSet="2"> <Tool Name="VCCLCompilerTool" AdditionalOptions="/Zm800 /Zm800 /Zm800 /Zm800 " InlineFunctionExpansion="1" AdditionalIncludeDirectories="../../../../;C:\Python22\include" PreprocessorDefinitions="NDEBUG;WIN32;_WINDOWS;_USRDLL;BOOST_PYTHON_DYNAMIC_LIB;BOOST_PYTHON_SOURCE" StringPooling="TRUE" RuntimeLibrary="2" EnableFunctionLevelLinking="TRUE" RuntimeTypeInfo="TRUE" PrecompiledHeaderFile=".\release-obj/boost_python.pch" AssemblerListingLocation=".\release-obj/" ObjectFile=".\release-obj/" ProgramDataBaseFileName=".\release-obj/" WarningLevel="3" SuppressStartupBanner="TRUE" CompileAs="0"/> <Tool Name="VCCustomBuildTool"/> <Tool Name="VCLinkerTool" AdditionalOptions="/MACHINE:I386" OutputFile=".\../bin-stage/boost_python.dll" LinkIncremental="1" SuppressStartupBanner="TRUE" AdditionalLibraryDirectories="C:\Python22\libs" ProgramDatabaseFile=".\../bin-stage/boost_python.pdb" ImportLibrary=".\../bin-stage/boost_python.lib"/> <Tool Name="VCMIDLTool" PreprocessorDefinitions="NDEBUG" MkTypLibCompatible="TRUE" SuppressStartupBanner="TRUE" TargetEnvironment="1" TypeLibraryName=".\../bin-stage/boost_python.tlb"/> <Tool Name="VCPostBuildEventTool"/> <Tool Name="VCPreBuildEventTool"/> <Tool Name="VCPreLinkEventTool"/> <Tool Name="VCResourceCompilerTool" PreprocessorDefinitions="NDEBUG" Culture="5129"/> <Tool Name="VCWebServiceProxyGeneratorTool"/> <Tool Name="VCWebDeploymentTool"/> </Configuration> <Configuration Name="Debug|Win32" OutputDirectory=".\../bin-stage" IntermediateDirectory=".\debug-obj" ConfigurationType="2" UseOfMFC="0" ATLMinimizesCRunTimeLibraryUsage="FALSE" CharacterSet="2"> <Tool Name="VCCLCompilerTool" AdditionalOptions="/Zm800 /Zm800 /Zm800 /Zm800 /Zm800 " Optimization="0" AdditionalIncludeDirectories="../../../../;C:\Python22\include" PreprocessorDefinitions="_DEBUG;WIN32;_WINDOWS;_USRDLL;BOOST_PYTHON_DYNAMIC_LIB;BOOST_PYTHON_SOURCE" BasicRuntimeChecks="3" RuntimeLibrary="3" RuntimeTypeInfo="TRUE" PrecompiledHeaderFile=".\debug-obj/boost_python.pch" AssemblerListingLocation=".\debug-obj/" ObjectFile=".\debug-obj/" ProgramDataBaseFileName=".\debug-obj/" WarningLevel="3" SuppressStartupBanner="TRUE" DebugInformationFormat="3" CompileAs="0"/> <Tool Name="VCCustomBuildTool"/> <Tool Name="VCLinkerTool" AdditionalOptions="/MACHINE:I386" OutputFile="../bin-stage/boost_python_debug.dll" LinkIncremental="1" SuppressStartupBanner="TRUE" AdditionalLibraryDirectories="C:\Python22\libs" GenerateDebugInformation="TRUE" ProgramDatabaseFile=".\../bin-stage/boost_python_debug.pdb" ImportLibrary=".\../bin-stage/boost_python_debug.lib"/> <Tool Name="VCMIDLTool" PreprocessorDefinitions="_DEBUG" MkTypLibCompatible="TRUE" SuppressStartupBanner="TRUE" TargetEnvironment="1" TypeLibraryName=".\../bin-stage/boost_python.tlb"/> <Tool Name="VCPostBuildEventTool"/> <Tool Name="VCPreBuildEventTool"/> <Tool Name="VCPreLinkEventTool"/> <Tool Name="VCResourceCompilerTool" PreprocessorDefinitions="_DEBUG" Culture="5129"/> <Tool Name="VCWebServiceProxyGeneratorTool"/> <Tool Name="VCWebDeploymentTool"/> </Configuration> </Configurations> <Files> <Filter Name="Source Files" Filter="cpp;c;cxx;rc;def;r;odl;idl;hpj;bat"> <File RelativePath="..\..\src\aix_init_module.cpp"> </File> <File RelativePath="..\..\src\converter\arg_to_python_base.cpp"> </File> <File RelativePath="..\..\src\converter\builtin_converters.cpp"> </File> <File RelativePath="..\..\src\object\class.cpp"> </File> <File RelativePath="..\..\src\dict.cpp"> </File> <File RelativePath="..\..\src\object\enum.cpp"> </File> <File RelativePath="..\..\src\errors.cpp"> </File> <File RelativePath="..\..\src\converter\from_python.cpp"> </File> <File RelativePath="..\..\src\object\function.cpp"> </File> <File RelativePath="..\..\src\object\inheritance.cpp"> </File> <File RelativePath="..\..\src\object\iterator.cpp"> </File> <File RelativePath="..\..\src\object\life_support.cpp"> </File> <File RelativePath="..\..\src\list.cpp"> </File> <File RelativePath="..\..\src\long.cpp"> </File> <File RelativePath="..\..\src\module.cpp"> </File> <File RelativePath="..\..\src\numeric.cpp"> </File> <File RelativePath="..\..\src\object_operators.cpp"> </File> <File RelativePath="..\..\src\object_protocol.cpp"> </File> <File RelativePath="..\..\src\object\pickle_support.cpp"> </File> <File RelativePath="..\..\src\converter\registry.cpp"> </File> <File RelativePath="..\..\src\str.cpp"> </File> <File RelativePath="..\..\src\tuple.cpp"> </File> <File RelativePath="..\..\src\converter\type_id.cpp"> </File> </Filter> <Filter Name="Header Files" Filter="h;hpp;hxx;hm;inl"> <File RelativePath="..\..\..\..\boost\python\arg_from_python.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\args.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\args_fwd.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\back_reference.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\base_type_traits.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\bases.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\borrowed.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\call.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\call_method.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\cast.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\class.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\class_fwd.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\copy_const_reference.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\copy_non_const_reference.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\data_members.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\def.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\default_call_policies.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\dict.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\enum.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\errors.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\exception_translator.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\extract.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\handle.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\handle_fwd.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\has_back_reference.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\implicit.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\init.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\instance_holder.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\iterator.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\list.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\long.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\lvalue_from_pytype.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\make_function.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\manage_new_object.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\module.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\module_init.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\numeric.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object_attributes.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object_call.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object_core.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object_fwd.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object_items.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object_operators.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object_protocol.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object_protocol_core.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object_slices.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\operators.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\operators2.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\other.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\overloads.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\pointee.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\proxy.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\ptr.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\refcount.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\reference_existing_object.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\return_internal_reference.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\return_value_policy.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\scope.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\self.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\signature.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\slice_nil.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\str.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\tag.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\to_python_converter.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\to_python_indirect.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\to_python_value.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\tuple.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\type_id.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\with_custodian_and_ward.hpp"> </File> <Filter Name="detail" Filter=""> <File RelativePath="..\..\..\..\boost\python\detail\aix_init_module.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\api_placeholder.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\arg_tuple_size.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\borrowed_ptr.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\call_object.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\caller.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\char_array.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\config.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\construct.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\convertible.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\cv_category.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\decorated_type_id.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\def_helper.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\defaults_def.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\defaults_gen.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\dependent.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\destroy.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\exception_handler.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\force_instantiate.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\if_else.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\indirect_traits.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\make_keyword_range_fn.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\make_tuple.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\map_entry.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\member_function_cast.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\module_base.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\module_init.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\msvc_typeinfo.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\none.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\not_specified.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\operator_id.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\overloads_fwd.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\pointee.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\preprocessor.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\python22_fixed.h"> </File> <File RelativePath="..\..\..\..\boost\python\detail\raw_pyobject.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\referent_storage.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\result.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\returning.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\scope.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\string_literal.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\target.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\translate_exception.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\type_list.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\type_list_impl.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\type_list_impl_no_pts.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\type_list_utils.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\unwind_type.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\void_ptr.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\void_return.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\detail\wrap_python.hpp"> </File> </Filter> <Filter Name="converter" Filter=""> <File RelativePath="..\..\..\..\boost\python\converter\arg_from_python.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\arg_to_python.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\arg_to_python_base.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\builtin_converters.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\constructor_function.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\convertible_function.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\from_python.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\implicit.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\obj_mgr_arg_from_python.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\object_manager.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\pointer_type_id.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\pyobject_traits.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\pyobject_type.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\pytype_arg_from_python.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\pytype_object_mgr_traits.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\registered.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\registered_pointee.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\registrations.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\registry.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\return_from_python.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\rvalue_from_python_data.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\converter\to_python_function_type.hpp"> </File> </Filter> <Filter Name="object" Filter=""> <File RelativePath="..\..\..\..\boost\python\object\add_to_namespace.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\class.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\class_converters.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\class_detail.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\class_wrapper.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\construct.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\enum_base.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\find_instance.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\forward.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\function.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\function_handle.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\function_object.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\inheritance.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\instance.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\iterator.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\iterator_core.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\life_support.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\make_holder.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\make_instance.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\pickle_support.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\pointer_holder.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\py_function.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\select_holder.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\value_holder.hpp"> </File> <File RelativePath="..\..\..\..\boost\python\object\value_holder_fwd.hpp"> </File> </Filter> </Filter> <Filter Name="Resource Files" Filter="ico;cur;bmp;dlg;rc2;rct;bin;rgs;gif;jpg;jpeg;jpe"> </Filter> </Files> <Globals> </Globals> </VisualStudioProject>

1 0

pyste and static const members.
by Giulio Eulisse April 30, 2003

April 30, 2003

The following code: --- #include <string> class Foo { public: static const std::string foo; }; --- Using Include("string") Foo=Class("Foo","foo.h"); as pyste file generates: [...] class_< Foo >("Foo", init< >()) .def(init< const Foo & >()) .def_readwrite("foo", &Foo::foo) ; [...] Which, when compiled, gives: foo.cpp: In function `void init_module_bar()': foo.cpp:14: no matching function for call to `boost::python::class_<Foo, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>::def_readwrite(const char[4], const std::string*)' Why is that? Do I have to wrap all the static members into getter/setter methods? Ciao, Giulio PS: Nicodemus: I'm working on the additional qtextedit infos...

2 3

SWIG: overriding virtual functions in Python.
by Jacek Generowicz April 28, 2003

April 28, 2003

given a C++ class struct foo { virtual void one() { cout << "This is foo::one() calling two()" << endl; two(); } virtual void two() { cout << "This is foo::two()" << endl; } }; I would like to subclass it in Python and override "two()" thus: class bar(foo): def two(self): print "This is bar.two()" in such a way that calling bar.one() ... bar().one() gives the result This is foo::one() calling two() This is bar.two() rather than This is foo::one() calling two() This is foo.two() In Boost this is achieved by doing providing a wrapper class around the original C++ implementation, and giving it a default implementation of the virtual function, which calls back into Python. Is there a way of doing it in SWIG?

2 2

pointers and pyste
by Sameer Agarwal April 27, 2003

April 27, 2003

Hello Boosters, thank you for a wonderful library. I am a c++ newbie trying to write a ray tracer and making it scriptable in python using boost. I have had a fair amount of success but I have a question to which the answer was not entirely clear in the documentation or the faq. I have a c++ class which stores pointers to a set of c++ objects class B { void render() } class A { list<B*> blist; void add_b(B*) { blist.push_back(B*) } void render() { //iterate over list blist // and call the render method on each object. } } which I wrapped using pyste. I also wrapped the class B using pyste. now I initialized a copy of B in python and passed it to add_b to add it to blist. so far so good. The problem starts when I call the render method in A which in turn calls the render method on each of the classes stored in blist. since I was using pyste to wrap the class, the render method being called turned out to be the one associated with the wrapped object(a subclass of B from what I can gather) and not the actual class B. This causes problems since there was some additional funkiness with the way the wrapped method was handling some references. However putting an explicit exclude statement in the pyste files to exclude the render method for class B solved the problem. Is there a problem here ? is this the standard way of doing stuff ? it seems quite cumbersome to exclude methods like this. thanks. sameer

3 6