Mailman 3 April 2013 - Cplusplus-sig

boost::python embedding error - runtime - Mac OS X - 1.38
by Igor Karpov Oct. 1, 2014

Oct. 1, 2014

Hi, I am trying to run the following program: #include <iostream> #include <Python.h> #include <boost/python.hpp> using namespace boost::python; using namespace std; int main(int argc, char** argv) { { // Using Python/C Py_Initialize(); PyObject* main_module = PyImport_ImportModule("__main__"); PyObject* globals = PyEval_GetGlobals(); PyObject* locals = PyEval_GetLocals(); PyRun_SimpleString("print 'Hello World, from Python/C!'\n"); Py_Finalize(); } { // Using boost::python Py_Initialize(); object main_module = import("__main__"); object main_namespace = main_module.attr("__dict__"); try { object ignored = exec("print 'Hello World, from boost::python!'\n", main_namespace); Py_Finalize(); } catch (error_already_set const& e) { PyErr_Print(); return 1; } } return 0; } on Linux (both x86 and x86_64), with Ubuntu's default version of Boost (1.34.1) installed, I am able to do so as expected: $ ./embed Hello World, from Python/C! Hello World, from boost::python! on Mac OS X, I get a runtime error: $ ./embed Hello World, from Python/C! Bus Error Running with gdb, this is the stack trace: Hello World, from Python/C! Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () #1 0x00bb618f in PyEval_GetGlobals () #2 0x00bce0dd in PyImport_Import () #3 0x00bce2b0 in PyImport_ImportModule () #4 0x008127d4 in boost::python::import (name=@0xbffff4a8) at libs/python/src/import.cpp:20 #5 0x00004446 in main (argc=1, argv=0xbffff510) at embed.cc:22 For this Mac, boost version is latest (1.38) and python version is: Python 2.5.4 (r254:67917, Dec 23 2008, 14:57:27) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Is this a bug? I attached the source and the cmake file I am using to build, for convenience. Thanks, --Igor.

4 6

sendkeys method
by sam Sept. 30, 2013

Sept. 30, 2013

Hello, Is there away(method) in C/C++ programming that make the software think that someone pressed the OK button, similar to sendkeys in VBS (WshShell.SendKeys ("{Enter}")) Thank you, Sam

4 5

pygccxml
by Kostyrka (External user) Andreas May 3, 2013

May 3, 2013

Hi! I just wondered where the authorative repository for pygccxml/pyplusplus are? The sf.net ones seem to lack commits for rather long periods of time. TIA, AndreasThe information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.

1 1

Biggest Fake Conference in Computer Science
by eliswilson＠hushmail.com May 3, 2013

May 3, 2013

Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP http://sites.google.com/site/worlddump1 organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia richer. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. This fake paper is different from the two fake papers already published (see https://sites.google.com/site/worlddump4 for details) in WORLDCOMP. We MUST say that you should look at the above website if you have any thoughts of participating in WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and threatens the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Prof. Hamid Arabnia makes a lot of tricks. For example, he appeared in a newspaper to fool the public, claiming him a victim of cyber-attack (see Item 8 in Section 5 of above website). Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! We ask Prof. Hamid Arabnia to publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also ask him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 and respond if he has any professional values. Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities at http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.

3 2

Embedding Python Question
by The Novice Coder April 30, 2013

April 30, 2013

Hi, hi! New user, and probably making some silly mistakes, but a few hours with search engines have not provided an answer... Problem: I'm trying to embed Python routines in a DLL and it's not working. Platform and versions: Python 2.7.3 (I have been unable to get boost to compile/link to python 3) Boost 1.54 (svn 84094) Windows 7 (x32) - MSVC 9 Detailed problem: When calling Py_Initialize() an assertion fails the program crashes in object.c line 65- assert((op->_ob_prev == NULL) == (op->_ob_next == NULL)); Test Code: Py_Initialize(); /* Failure point */ m_main_module = boost::python::import("__main__"); m_main_namespace = m_main_module.attr("__dict__"); boost::python::exec("result = 5 ** 2", m_main_namespace); int Tester = boost::python::extract<int>(m_main_namespace["result"]); Values: + op 0x05be172c __Py_NoneStruct {_ob_next=0x00000011 _ob_prev=0x00000000 ob_refcnt=17 ...} _object * + op->_ob_next 0x00000011 {_ob_next=??? _ob_prev=??? ob_refcnt=??? ...} _object * + op->_ob_prev 0x00000000 {_ob_next=??? _ob_prev=??? ob_refcnt=??? ...} _object * Partial Call Stack: msvcr90d.dll!__wassert() + 0xb64 bytes python27_d.dll!_Py_AddToAllObjects(_object * op=0x05be172c, int force=0) Line 65 + 0x2d bytes C python27_d.dll!_PyBuiltin_Init() Line 2680 + 0x2d bytes C python27_d.dll!Py_InitializeEx(int install_sigs=1) Line 214 + 0x5 bytes C python27_d.dll!Py_Initialize() Line 377 + 0x7 bytes C pySim_plugd.dll!PySimProcessor::PySimProcessor() Line 73 + 0x8 bytes C++ Attempted solutions: Tried adding call to Py_Initialize() from main() - Call succeeded, but no effect on module. Tried moving call to Py_Initialize() from main() - Python code fails to execute. Tried duplicating same code in different application - succeeded. =( Thanks for reading!

1 0

question on boost.python exception mechanisms
by Holger Joukl April 30, 2013

April 30, 2013

Hi, I'm wrapping a C++ library that's actually just a thin wrapper around a C lib. Through a dispatch() method of a Dispatcher class there's an invocation of callbacks which get implemented on the Python side, by subclassing callback classes exposed through Boost.Python. Now, for performing the actual dispatch the C++ library calls into the underlying C library. This hasn't been a problem so far as we've been targetting Solaris using Sun/Oracle studio compilers. However, on Linux compiled with GCC, if an exception gets raised in the Python callback the program segfaults. Obviously the C part of the vendor library has not been compiled with (GCC-) exception support for Linux. Unfortunately this isn't under my control and the library provider seems not to be willing to make the library robust against exceptions in user callback code. So I need to keep the Boost C++ exception that "signals" the Python exception from passing through the C parts. Instead of introducing some custom error/exception notification scheme I *think* I can simply do this: As I need wrapper classes for the virtual method override mechanisms anyway I can just ignore/suppress the exception in the callback wrapper layer and re-throw the exception again in the dispatcher, provided that in between we do not return to Python and no other call into Python is made: I.e. The callback wrapper simply suppresses the C++ exception "signalled" for the Python exception: class CallbackWrap : public Callback, public bp::wrapper<Callback> { // pure virtual so no need for default implementation // virtual void onMsg(MsgListener* listener, Msg& msg) = 0; virtual void onMsg(MsgListener* listener, Msg& msg) { try { this->get_override("onMsg")(bp::ptr(listener), boost::ref (msg)); } catch (const bp::error_already_set& e) { if (PyErr_Occurred()) { // Do nothing: The Dispatcher that invoked the callback // MUST check if a Python error has been set and re-throw } } } }; The Dispatcher is then responsible for re-throwing, to not let the Python exception go undetected when returning to the Python world: // virtual Status dispatch (); virtual Status dispatch() { Status ret; if (bp::override f = this->get_override("dispatch")) { ret = f(); // *note* } else { ret = Queue::dispatch(); } if (PyErr_Occurred()) { // Re-throw the error that stems from the Python exception in the dispatched callback bp::throw_error_already_set(); } return ret; } Does this sound sane? Any hints appreciated, Holger Landesbank Baden-Wuerttemberg Anstalt des oeffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz HRA 12704 Amtsgericht Stuttgart

3 14

Re: [C++-sig] Custom PyTypeObjects
by Alex Leach April 29, 2013

April 29, 2013

Dear list, A thread I started was originally meant to discuss how to use C++ memory management methods (operator new, delete etc.) with a boost python instance. Rather than dwelling on the concern, I've been (successfully) wrapping other code since, but have now arrived at a separate conundrum, which I think could be addressed by the same conceptual solution. This time I've found a working attempt at a solution here on this list[1], and was hoping that more generic, template-ised versions could be introduced into Boost.. [1] - http://mail.python.org/pipermail/cplusplus-sig/2007-August/012438.html The message has turned into a bit of an essay, so I'll summarise what I've written here:- * Python objects and protocols - they're not all the same. * Python Buffers - An example and attempt at exposing one. * C++ IO streams - exposing buffered object interfaces to Python. * Customising PyTypeObjects already used in Boost Python. * "There should be one-- and preferably only one --obvious way to do it." * Summary What's in an Object? -------------------- What I think it boils down to is a lack of support for the different type objects defined in the Python C-API Abstract[2] and Concrete[3] Object Layers. The problem in [1] was related to PyBufferProcs and PyBufferObjects. How can an object representing a buffer be properly exposed to Python? The PyBuffer* structs were designed with this in mind, but are now deprecated in favour of memory view objects [4]. Either way, a `grep` of the Boost Python header and source files show no sign of either API being made of use. [2] - http://docs.python.org/2/c-api/abstract.html [3] - http://docs.python.org/2/c-api/concrete.html [4] - http://docs.python.org/2/c-api/buffer.html#memoryview-objects A buffered solution ------------------- The solution from [1] makes it about as simple as possible for the client / Python registration code to expose a return type that is managed by a PyBuffer_Type-like PyTypeObject. A custom to-python converter is registered and return_value_policy used. However, this is still fairly cumbersome compared to current Boost Python usage, as the C-Python API needs to be used directly and a custom PyTypeObject defined, for any return-type that should use a different type protocol. The solution also goes nowhere to providing the functionality a Python buffer expects, but instead just demonstrates how one might use a new PyTypeObject. A standards-compliant solution ------------------------------ With the C++ standard library in mind, I was wondering what boost python might be able to do with IO streams. I have a family of C++ classes that use iostream-like operators to serialise objects into either XML, plain text, or binary formats. Providing this functionality via a buffered object seems to be the appropriate solution... Using boost python to expose such an interface though, looks non-trivial, to say the least. A boost-friendly solution might be to recognise boost::asio::buffer[6] objects, perhaps using boost::mpl statements in the to-python converter registrations. I'm still trying to get to grips with standard library templates personally, so would prefer if classes derived from ios_base could automatically have their '<<' and '>>' operators exposed at compile time, depending on whether they are read-only or read-write. An exposed seek function would also be useful, when one is available in the C++ type. Specialised PyTypeObjects ------------------------- Discussing each of the different object types is too large a subject to describe in full here, but would it not be sensible for Boost Python to make it easier to expose other PyTypeObjects? The NumPy C-API exposes 8 public and 4 private type specialisations[5], for representing clearly different types of data. These are essentially PyTypeObjects conforming to the API defined in the C-Python object layers documentation[2,3]. With quite a lot more code, Boost Python could potentially provide capability to specialise the type objects for a number of pre-defined base types, by providing custom HolderGenerators[6] for each type specialisation. These HolderGenerators can be referred to by creating corresponding `return_value_policy`s. This is what the solution from [1] does, by defining both a new HolderGenerator and a corresponding return_value_policy. This concept is not problem-free, however. In my case, I'd like to tie a C++ class's streaming interface directly to the PyTypeObject. For Python 2.x this would mean populating a new PyTypeObject's tp_as_buffer attribute to a PyBufferProcs struct. The code from [1] could be modified to do this, but it would take quite a lot more work. (It has..) For Python2.7 and above, there are of course the new buffer and memoryview APIs, but I haven't really read up on or done anything with them yet... [5] - http://docs.scipy.org/doc/numpy/reference/c-api.types-and-structures.html [6] - http://www.boost.org/doc/libs/1_53_0/libs/python/doc/v2/HolderGenerator.html A generalised solution ---------------------- To answer my question from the previous thread I started here, on how to use a custom PyTypeObject on an exposed class_<> hierarchy, I think the way to do this is to use `pytype_object_manager_traits<PyTypeObject*, object>`, as is done in str.hpp, list.hpp, etc. e.g.:- namespace converter { template <> struct object_manager_traits<str> : pytype_object_manager_traits<&PyUnicode_Type, str> { }; } This seems to be the best way to register a PyTypeObject to a C++ class, with Boost. But it does require a tremendous of work, when wanting to use PyTypeObjects that should use STL functionality. C++ IO streams -------------- Mapping C++ STL functions to PyTypeObject attributes[7] does not appear to have been done at all in Boost Python, in so far as I can tell. Of course there are the standard objects, bp::string, list, etc. , which use core Python's respective PyTypeObjects as instance managers, like above, but it doesn't seem like there is a robust way to replace a PyTypeObject's function pointers with STL-conforming implementations. I suppose it is possible to edit the PyTypeObject, after getting it with `object.get_type()`, but that seems a bit of an inefficient, run-time hack. I was playing around with the code from [1] over the weekend, and have started to map the C++ iostream template functions to a PyTypeObject's `tp_as_buffer` member struct, to expose buffered access to C++ formatted stream methods through a PyBufferProcs struct[8]. Admittedly, this was a bit of a pointless exercise, as the buffer protocol has been removed in Python 3, but I am currently developing with Python 2.7 and wanted to try out an initial, working implementation where a custom PyTypeObject is used. For std::i/ostream, there is some production code available that can perform Python file-like object conversions. In particular, the two subsequent replies to this message[9] here on this list, mention open-source libraries that can already do this. And from the code listed in [1], I've made available yet another (partially complete) implementation[10]. [7] - http://docs.python.org/2/c-api/typeobj.html# [8] - http://docs.python.org/2/c-api/typeobj.html#PyBufferProcs [9] - http://mail.python.org/pipermail/cplusplus-sig/2010-March/015411.html [10] - https://github.com/alexleach/bp_helpers Moving forward -------------- Assuming Boost Python follows the Zen of Python, there should be one - and only one - obvious way to achieve what I want. That is currently, to expose a future-proof, STL-compliant iostream interface, through Boost Python. I don't think any of the above implementations are compatible with Python 3, since I don't think any of them use the new Python buffer or memoryview APIs, but I'd like to make the switch soon, myself. I'm sure adding buffer support to Boost Python would be valuable for a number of users. From a backwards-compatibility perspective, it would probably be good to have both the old and the new buffer APIs included in Boost Python, to be selected with a Python preprocessor macro. Memoryviews are a relatively fancy and new feature, but buffers have been around for ages, so it would be good if they were supported, for basically all versions of Python. Ideally though, we would also have memoryview functionality in v2.7+, too. One way to rule them all ------------------------ Now, I've discovered a number of ways to write to_python converters, and am not sure what is the "one obvious way" to define a new PyTypeObject's API. I would be grateful for feedback on which should be the preferred way to expose a class with a custom PyTypeObject. Here are the methods I've looked into:- 1. indexing_suite Perhaps my favourite way I found to expose a to_python converter, was with boost python's indexing_suite, as I did for std::list[11] (also attached to a msg on this list, earlier this month). From the client's perspective, all that needs to be done is to instantiate a template. For examples, see the C++ test code[12]. However, I haven't really looked into how the converter is registered internally, as the base classes take care of that. Either way, the indexing suite functions are only attached to the PyObject, not its respective PyTypeObject. [11] - https://github.com/alexleach/bp_helpers/blob/master/include/boost_helpers/m… [12] - https://github.com/alexleach/bp_helpers/blob/master/src/tests/test_make_lis… 2. class_<..> The code for the class_ template, its bases and typedefs is really quite advanced, but it can't be said that it is inflexible. Still, I haven't found an "obvious way" to replace a class's object manager. I get a runtime warning if a to_python_converter is registered as well as a class. bp::init has an operator[] method, which can be used to specify a CallPolicy, but I haven't managed to get that to change an instance's base type. The registry is probably the way to do this, but for me at least, the registry is very opaque, so I haven't found a good way to edit or replace a PyTypeObject, either during or after an exposed class_<> has been initialised. 3. to_python_converter<class T, class Conversion, bool has_get_pytype=false> This is how the solution in [1] enables to-python (PyObject) conversion, and is also how I've been doing it in the testing code I modified from there[13-15]. A corresponding Conversion class seems necessary to write, for each new type of PyTypeObject. e.g. as done in return_opaque_pointer.hpp and opaque_pointer_converter.hpp. [13] - https://github.com/alexleach/bp_helpers/blob/master/src/tests/test_buffer_o… [14] - https://github.com/alexleach/bp_helpers/blob/master/include/boost_helpers/r… [15] - https://github.com/alexleach/bp_helpers/blob/master/include/boost_helpers/b… 4. Return value policies and HolderGenerators In functions and methods where a CallPolicy can be specified, as I've said already, a custom CallPolicy can be used to refer to a custom HolderGenerator. These specify which PyTypeObject is used for managing the python-converted object, but can a custom return value policy and holder be specified with the class_<> template? I sure would like to find a way... However, alone, this doesn't seem to put a type converter in the registry. I thought that the MakeHolder::execute function should only need to be called once, but my code is currently calling it every time I want a new Python instance. So, I think I must not be registering the class' type id properly[14]... Then there are the lvalue and rvalue Python converters, which admittedly I don't know much about. There's also some other concepts I haven't mentioned above, like install_holders[16], for example, and whatever is done when you add shared_ptr<X> to the class_ template's arguments. [16] - http://www.boost.org/doc/libs/1_53_0/libs/python/doc/v2/instance_holder.htm… Summary ------- Should the ability to expose C++ istreams and ostreams be added to Boost Python? How should this be done? I thought that having a chainable return_value_policy for both istreams and ostreams would be great. That way they could be both used in conjunction for an iostream, with the functionality just incrementally added to a base PyTypeObject. But I don't see how one could attach additional PyObject methods, like done by a class_ template's def methods. What about memoryviews? If someone was to go ahead and write converters for Python memoryviews, are there any C++ standards-compliant classes that could be accommodated? i.e. Are there any classes defined in the C++ standard for multidimensional, buffered memory access? Which, if any would be an appropriate match to a Python memoryview? I guess that nested std::vectors and lists might be good candidates, but I stand to be corrected. Apologies for the length this became and thank you for sticking with me this far. Any advice, suggestions, pointers to code or documentation I've probably overlooked or neglected, or even criticism would be appreciated. Further discussion on how best to improve Boost Python as it is would be great! I do like to contribute to open source communities when possible, but I am strained for time... Thanks again! Kind regards, Alex

1 0

pylab not properly working when embedded into Qt
by Jan Müller April 24, 2013

April 24, 2013

Hi! I try to embed python into a Qt C++ application. I don't need any speciality, just run some prepared scripts from time to time. E.g. I have a function which should do some plotting through pylab. When I call this function ("run", see below) from the main (GUI) thread, everything works fine and as expected. But as soon as I spawn a new thread to run this function in it, it stops to work ('hangs' forever?) Strangely, the problem only shows up when I call 'import pylab'. It seems everything else which I tested (all other non-pylab related python code) works fine even when executed from any thread. I need to run the python scripts in a different thread than the main thread (which also controls the GUI) to keep the application responsive while running longer scripts. int run() { Py_Initialize(); PyGILState_STATE state = PyGILState_Ensure(); PyRun_SimpleString("import pylab; pylab.plot([1,2]); pylab.show();"); PyGILState_Release(state); Py_Finalize(); } // the function from the Qt GUI-thread (main thread) works fine // (with any python string in PyRun_SimpleString() ) run(); // but this blocks forever at 'import pylab' std::thread t = std::thread(run); t.join(); (I call Py_Initialize only once in the program) Could this be a threading issue? I don't think so, because even when the qt app uses multiple threads, only one of it accesses python variables. It seems to me, pylab does not like it when another thread controls the GUIs!?! Is there a work around/fix? What do I miss? I tried putting Py_Initialize/Py_Finalize also into the main thread, but it didn't made any difference. Many thanks for any hints! Regards, Jan

2 1

building Boost.Python with
by Christian Staudt April 22, 2013

April 22, 2013

Hello cplusplus-sig, I would very much like to provide my C++ project with a Python 3 interface. Boost.Python seems like a good option, but I have trouble getting started. I believe I need to build Boost.Python from source against my Python3.3 installation, but I am running into problems which I wasn't able to solve with the help of [1]. Is it appropriate on this list to ask for support in the build process? Would anyone be willing to look into the issue? Chris [1]: http://www.boost.org/doc/libs/1_53_0/libs/python/doc/building.html

2 1

Tips for exposing classes with own memory management model
by Alex Leach April 19, 2013

April 19, 2013

Dear list, Apologies if this has been asked before, but I'm struggling to find anything strictly related.. Background ---------- This library I'm trying to wrap uses its own memory management model, where almost every class derives from an object with loads of memory management-related member functions; it also has a couple of friend classes related to counting and locking. I don't intend to expose any of these memory-related functions or friend classes to Python, but I was thinking that performance could be quite badly affected if both Python and C++ code are performing separate memory management implementations. Optimal memory usage -------------------- I would suppose that memory usage on class instances would probably contain unnecessary bloat too, as I think each exposed class instantiation would allocate memory for a normal PyObject as well as unexposed C++ member functions. Right thing to do ----------------- I initially hoped to use a 'return_internal_reference' CallPolicy on the class_<..> init calls, but I doubt that is The Right Thing To Do. Would it be a better design to define a PyTypeObject for this C++ base class and its friends? If I did, could I still use functions in boost::python? I don't think PyTypeObject's are supposed to be derived, so I don't have a clue what extra I'd have to do to make it work with Boost::Python. How should one proceed with this? Links to archived emails or documentation would be great.. If I can conjure up something good enough for Boost, I'd be happy to contribute, if possible. Thanks for your time, and kind regards, Alex

3 5