[C++-sig] Re: sub module support in V2

Dave Hawkes daveh at cadlink.com
Wed Jun 5 19:08:27 CEST 2002


"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:17ac01c20cac$9932b2a0$6601a8c0 at boostconsulting.com...
> I like the idea of supporting sub-modules, but your interface makes no
> sense to me.
> For one thing, I don't want to introduce a new class for sub-modules;
> module itself should suffice.
>

I agree, this was just a test class and is what I intended by mentioning
integrating it in to the module code, but I wasn't particularly explicit..

> > BOOST_PYTHON_MODULE_INIT(PyTest)
> > {
> >   boost::python::sub_module("PyTest")
>
> Makes PyTest a sub-module of what?

Nothing, it's the main module, this was just my test code so I did not have
to modify module.hpp

>
> >    .def("Test1",Test1)
>
> Defines PyTest.Test1
>
> >    .sub("sm")
>
> ".sub" is a nasty abbreviation. We only use ".def" because of Python
>

We could use sub_module (as the sub_module class will go), but is that too
verbose?

> > .def("Test2", Test2);
>
> Suppose I want to add a 2nd sub-module of PyTest?
>

Then we'll have to resort to this (or variation of):

boost::python::sub_module m("PyTest");
m.def("Test1", Test1).sub("sm").def("Test2", Test2);
m.sub("sm2").def...

> Furthermore, I think "import sm" now imports PyTest.sm in your example,
> which I presume was not intended.
>

Unfortuantely, yes, something will have to be done about Py_InitModule,
which call PyImport_AddModule. Maybe we should just delete the sys.modules
entry that is produced as a result? Unless there is a more elegant solution.

I'd also like to add some code that checks if a sub-module of the same name
already exists and return a reference to that rather than a new sub-module
so we don't lose previous definitions.

Dave Hawkes










More information about the Cplusplus-sig mailing list