[C++-sig] Multiple calls to bp::detail::init_module() causing conflicts?
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 [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Multiple calls to bp::detail::init_module() causing conflicts?
Hi Austin, Just a remark: the python3 support isn't routinely exercised. Overlooked incompatibilities are possible. I only have time to maintain the python2 support. We need a volunteer to port the unit tests to python3. Ralf - Original Message > From: Austin Bingham > To: Development of Python/C++ integration > Sent: Mon, December 20, 2010 7:04:06 AM > Subject: [C++-sig] Multiple calls to bp::detail::init_module() causing >conflicts? > > 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 > [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] Multiple calls to bp::detail::init_module() causing conflicts?
I'm happy to help with this, at least as my time permits. I've looked at the docs regarding the regression tests, and everything seems fairly straightforward (though I've never really wrapped my head around jam!). Is it just a question of building boost against python3, running the tests, and fixing whatever breaks? Austin On Tue, Dec 21, 2010 at 12:48 AM, Ralf W. Grosse-Kunstleve wrote: > Hi Austin, > Just a remark: the python3 support isn't routinely exercised. > Overlooked incompatibilities are possible. > I only have time to maintain the python2 support. We need a > volunteer to port the unit tests to python3. ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Multiple calls to bp::detail::init_module() causing conflicts?
> From: Ralf W. Grosse-Kunstleve > To: Development of Python/C++ integration > Sent: Tue, December 21, 2010 12:48:35 AM > Subject: Re: [C++-sig] Multiple calls to bp::detail::init_module() causing >conflicts? > > Hi Austin, > Just a remark: the python3 support isn't routinely exercised. > Overlooked incompatibilities are possible. > I only have time to maintain the python2 support. We need a > volunteer to port the unit tests to python3. > Ralf > I'm testing release branch against python 3 (see Trigve in http://www.boost.org/development/tests/release/developer/summary.html). Adding trunk testing against python 3 would be also welcomed. Trigve ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
