[Swig-devel] 3.0.7 vs 3.0.8 : problem in __init__

[Pierre-Henri WUILLEMIN]

Dear all,

I am wrapping a quite large C++ library in python (2 and 3) using swig 3.0.7.

I just checked today what would happen when using the current swig 3.0.8
version in branch master . And I found a big problem !

The very same code/*.i files that are correct and usable with swig 3.0.7 now
generate error when running python code that uses the wrappers ...

The prototype of errors is

Traceback (most recent call last):
File "TestSuite.py", line 69, in testLocalSearchWithTabuAccurate
.../...
File "build/wrappers/project/project.py", line 6210, in __init__
self.this.append(this)
File "build/wrappers/project/project.py", line 6195, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, myClass, name)
File "build/wrappers/project/project.py", line 81, in _swig_getattr
return _swig_getattr_nondynamic(self, class_type, name, 0)
File "build/wrappers/project/project.py", line 76, in
_swig_getattr_nondynamic
return object.__getattr__(self, name)
AttributeError: type object 'object' has no attribute '__getattr__'


I have errors of that kind for many (if not all) __init_ of wrappers. For
now I can only see that many (if not all)

try:
self.this.append(this)
except:
self.this=this

became

try:
self.this.append(this)
except Exception:
self.this=this

in the new generated python code for the library... which explains nothing, I
guess ...

I will try to investigate the reason of these errors. But if anyone could give
me any clue about what has changed that could explained why all the
constructors of my wrapped classes seem to be bugged in 3.0.8 and not in
3.0.7, I would be very grateful :-)

Best regards,

[William S Fulton]

On 2 November 2015 at 15:23, Pierre-Henri WUILLEMIN

Post by Pierre-Henri WUILLEMIN
Dear all,
I am wrapping a quite large C++ library in python (2 and 3) using swig 3.0.7.
I just checked today what would happen when using the current swig 3.0.8
version in branch master . And I found a big problem !
The very same code/*.i files that are correct and usable with swig 3.0.7 now
generate error when running python code that uses the wrappers ...
The prototype of errors is
File "TestSuite.py", line 69, in testLocalSearchWithTabuAccurate
.../...
File "build/wrappers/project/project.py", line 6210, in __init__
self.this.append(this)
File "build/wrappers/project/project.py", line 6195, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, myClass, name)
File "build/wrappers/project/project.py", line 81, in _swig_getattr
return _swig_getattr_nondynamic(self, class_type, name, 0)
File "build/wrappers/project/project.py", line 76, in
_swig_getattr_nondynamic
return object.__getattr__(self, name)
AttributeError: type object 'object' has no attribute '__getattr__'
I have errors of that kind for many (if not all) __init_ of wrappers. For
now I can only see that many (if not all)
self.this.append(this)
self.this=this
became
self.this.append(this)
self.this=this
in the new generated python code for the library... which explains nothing, I
guess ...
I will try to investigate the reason of these errors. But if anyone could give
me any clue about what has changed that could explained why all the
constructors of my wrapped classes seem to be bugged in 3.0.8 and not in
3.0.7, I would be very grateful :-)

This pull request https://github.com/swig/swig/pull/509 is responsible
for the except change, but not sure that is the cause.

I don't think much else has changed in the Python wrappers. I suggest
doing a diff on the generated c++ code for anything else.

William

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

[Pierre-Henri WUILLEMIN]

Hello and thank you William,

I found the problem which was of course in our code : we have a C++ exceptions
hierarchy that is wrapped in python and begins with a base class "Exception".
In C++, it is encapsulated in our namespace (so no problem) but it is not true
anymore in python.

I just %rename our exception class and it is ok.
Sorry for that !

PS- It would be safer to import the compiled package in a namespace :

When wrapping a project "package", at the beginning of the package.py file

import _package # import _package.so

should be

import _package as _PACKAGE

to remove the risk of such a collision ???


Best regards,