Ah, you’ve linked your SWIG-generated C++ module into the application that contains the Python interpreter.


Perhaps myModule.py does this:


import myPackage._myModule


which makes the interpreter load the .pyd, since this seems to ask for something different from what’s already in memory.  You could check, and if so try changing that to


import _myModule





From: Olivier Voyer [mailto:olivier.voyer@gmail.com]
Sent: Friday, August 29, 2014 4:39 PM
To: Cherry, Josh (NIH/NLM/NCBI) [E]
Cc: swig-user@lists.sourceforge.net
Subject: Re: [Swig-user] Initialize a sub-module within a package with SWIG and Python 3


Thank you for your answer.


I was already using the -py3 option.


There is something in the documentation which I'm not sure about: "It's up to you to place the generated module files (.py.so) in appropriate subdirectories". I'm a bit lost here. In my old Python 2.7 code, I didn't used the .pyd files, since everything was loaded in memory by my C++ application (it actually called the SWIG_InitializeModule function in the module_wrap.cpp file). Then, when I called "import myPackage.myModule", Python was able to load the module in memory. In fact, the .pyd were not used at all when Python was called from inside my C++ application (through Python/C API). But, with Python 3 this does not seem to work anymore.


Can someone confirm that this algorithm is good in Python 3:


1. PyImport_AppendInittab("myPackage.myModule", PyInit__myModule);

2. Py_Initialize();

3. PyInit__myModule(); // Calls SWIG_InitializeModule so the module is loaded in memory

4. PyRun_SimpleString( "import myPackage" ); // Runs fine

5. PyRun_SimpleString( "import myPackage.myModule" ); // ERROR


This is the error I get:


ImportError: dynamic module does not define init function (PyInit__myModule)


What bothers me is I can see in Visual Studio that it tries to load _myModule.pyd file, even though theoretically it should detect that myPackage.myModule is already loaded in memory.




On Fri, Aug 29, 2014 at 3:04 PM, Cherry, Josh (NIH/NLM/NCBI) [E] <jcherry@ncbi.nlm.nih.gov> wrote:

I presume that this has to do with the change in Python 3 to disallow implicit relative imports, which you can read about on the web if you haven’t already.  Specifically, I imagine it has to do with the import of _mySubmodule1 by mySubmodule1.py.  From my reading of the docs, the –py3 command-line switch should make this work right:







From: Olivier Voyer [mailto:olivier.voyer@gmail.com]
Sent: Friday, August 29, 2014 11:14 AM
To: swig-user@lists.sourceforge.net
Subject: Re: [Swig-user] Initialize a sub-module within a package with SWIG and Python 3


I'm sorry to ask again, but I really tried everything I could think of.


To summarize, here is my problem:


I have this structure on my drive:



-- __init__.py

-- mySubmodule1.py

-- mySybmodule2.py


And this code does not work with Python 3.4:

PyImport_AppendInittab("myPackage.mySubmodule1", PyInit__mySubmodule1);
PyRun_SimpleString("import myPackage"); // Works well. It finds the package on my drive because I added programmatically the package path to sys.path.
PyImport_ImportModule("myPackage.mySubmodule1"); // This line always returns NULL
// Test - does not work either
// PyRun_SimpleString("import myPackage.mySubmodule1");
Do I need to add something in the module.i file to indicate the module is in a package?
Here is what I have so far in my module.i:
%module(package="myPackage", docstring="Module doc") mySubmodule1


On Wed, Aug 27, 2014 at 2:07 PM, Olivier Voyer <olivier.voyer@gmail.com> wrote:

Hi all,


I'm trying to port my SWIG/Python code from Python 2.7 to Python 3.4 (to support UNICODE), but I can't find a way to import my sub-modules in embedded mode, i.e "import my_package.my_module" won't work when called from C++.


I've created a stackoverflow post, I was wondering if somebody would like to help me with this? We are on a tight schedule and I'm really stuck here...