Python wrapper returns SwigPyObject instead of CPACSWalls

[MarAlder]

I still can't figure out why the walls (CPACSWalls.h) are not being exported correctly with the Python bindings. Does anyone have an idea?

Minimal test code:

from tixi3.tixi3wrapper import Tixi3
from tigl3.tigl3wrapper import Tigl3
import tigl3.configuration

tixi_h = Tixi3()
tigl_h = Tigl3()

tixi_h.open("test_fuselage_walls_ex1.xml")
tigl_h.open(tixi_h, "")

mgr = tigl3.configuration.CCPACSConfigurationManager_get_instance()
aircraft_config = mgr.get_configuration(tigl_h._handle.value)
walls = aircraft_config.get_fuselage("fuselage").get_structure().get_walls()

help(walls)

Test data:
test_fuselage_walls_ex1.zip

Output:

class SwigPyObject(object)
 |  Swig object carries a C/C++ instance pointer
 |
 |  Methods defined here:
 |
 |  __eq__(self, value, /)
 |      Return self==value.
 |
 |  __ge__(self, value, /)
 |      Return self>=value.
 |
 |  __getattribute__(self, name, /)
 |      Return getattr(self, name).
[...]

tigl/bindings/python_internal/configuration.i

Lines 190 to 191 in f1e1bc3

	%boost_optional(tigl::generated::CPACSWalls)
	%include "generated/CPACSWalls.h"

[joergbrech]

Is there an #include "generated/CPACSWalls.h" missing in configuration.i? Note the # instead of the %.

[MarAlder]

I also thought so, but no effect (see 2e43950)

[joergbrech]

Sorry, could you try CCPACSWalls instead of generated/CPACSWalls.h?

[MarAlder]

Nice to see progress here, @merakulix! Perhaps we should strive to also cover such Python functions via unittests? I made an example on my fork for the tanks. The pythonwrapper tests are still at the old TiGL/TiXI versions.

[joergbrech]

Perhaps we should strive to also cover such Python functions via unittests?

I totally agree, but I wouldn't want to add it to this issue/PR-pair.

Any idea on a pragmatic way to achieve this? Here are some ramblings:

• Regardless on how we implement the Python tests, having them in CI would be an improvement.
• When we implement the python tests, we could agree that we don't actually have to test the functionality of the swig-wrapped classes in the Python unit tests, but that it suffices to just the existence of the classes in the Python interface. This would limit the maintenance overhead of TiGL. It might be possible to achieve this with some degree of automation, not sure. Without automation, every contributor must add these checks themselves and the reviewer must manually verify that all relevant checks are in place, which adds a (small) burden to the maintenance.
• We try to derive C++ and Python unit tests from a model-based testing approach. This would involve a lot of work to set the system up and the outcome is not clear: It could be an awesome new thing that boosts robustness or it could turn out to be too complex and impracticable, because it is really hard to formally model the process of modelling with TiGL/CPACS.

This is related to #826.

[MarAlder]

True, let's move this discussion to #826.