[Swig-devel] [ swig-Bugs-2143727 ] interface %import doesn't take package names into account

[SourceForge.net <no...@so...>]

Bugs item #2143727, was opened at 2008-10-03 06:15
Message generated for change (Comment added) made by wsfulton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2143727&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: python
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Serge Monkewitz (smonkewitz)
>Assigned to: William Fulton (wsfulton)
Summary: interface %import doesn't take package names into account

Initial Comment:
The python documentation (http://www.swig.org/Doc1.3/Python.html#Python_nn72) on python packages for modules states:

"Using the package option of the %module directive allows you to specify what Python package that the module will be living in when installed. This is useful when the .i file is %imported by another .i file. By default SWIG will assume that the importer is able to find the importee with just the module name, but if they live in separate Python packages then that won't work. However if the importee specifies what its package is with the %module option then the Python code generated for the importer will use that package name when importing the other module and also in base class declarations, etc. if the package name is different than its own."

This doesn't seem to be true in practice. As a test case, consider the following interface files:

first.i
----

%module(package="a") first
%inline %{
class base {
public:
       int foo(void) { return 1; }
};
%}

second.i
-------

%module(package="b") second
%import first.i
%inline %{
class derived : public base {
public:
       int bar(void) { return 2; }
};
%}

The python code generated by swig 1.3.36 for second.i contains

import first

rather than

import a.first

In case it's useful, I've attached a patch relative to swig 1.3.36 which fixes this issue for me. Caveat: I'm very far from being an expert on swig internals, and have not done extensive testing of this patch.



----------------------------------------------------------------------

>Comment By: William Fulton (wsfulton)
Date: 2008-12-02 20:21

Message:
Thanks, committed for 1.3.37.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=2143727&group_id=1645