I'm in the process of upgrading my project to boost-1.45.0 and python3, and I started seeing strange problems with some of my boost.python-based extension modules. Essentially, some of my modules are reporting the wrong module name, i.e. if I "print(module_object.__name__)", I get the wrong value. I threw this into gdb, and it looks like the problem might have to do with the implementation of bp::detail::init_module().
I ran python under gdb, but a breakpoint on init_module(), and imported the modules with which I'm seeing problems. The first call to init_module() initializes the static PyModuleDef struct "moduledef" properly. However, the second call shows that the "m_name" field it left as-is from the first call (since the object is static); I would have expected that it needs to be updated with the new module name. This stale (I think) module def is then used for the rest of the initialization, and I'm guessing that this is the cause of the problems I'm seeing. Certainly, it seems that the name of the first module imported seems to be getting used as the name of the second module. I only noticed this problem when I tried to pickle some of the types exposed by my module. The pickle module in python3 complained that it didn't know anything about the broken modules I was getting. Is this a bug in boost.python? I plan to write a small patch tomorrow to set the m_name field in init_module(), so maybe this will fix the problem. If this isn't a boost.python bug, does anyone have any idea what might be going wrong? And how is it correct that the static moduledef is reused without updating its name? Thanks, Austin _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
