[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