Python access impact on C++ refactoring

[FreddyFreddy]

It seems python has broad reach into c++ code.

I assume access is via named objects/classes etc, I think in xml files.

It appears then that refactoring c++ code could break existing python code.
If so, how to determine which c++ code is a dependency of such python code? I think the IDE has no way of knowing.

[marioalexis]

In the C++ code that conform the Python interface (usually generated by parsing .xml files), FreeCAD C++ objects are accessed via a pointer. So if you don't change the name of these classes or the signature of the members, it shouldn't affect the Python interface. Of course, in any case, you should check the impact of changes on the original classes in the Python interface.

[FreddyFreddy]

In the C++ code that conform the Python interface (usually generated by parsing .xml files), FreeCAD C++ objects are accessed via a pointer. So if you don't change the name of these classes or the signature of the members, it shouldn't affect the Python interface. Of course, in any case, you should check the impact of changes on the original classes in the Python interface.

But, But, But... How is possible to refactor c++ code when there are dependencies hidden in xml files? If this is right it is a huge disincentive to improve existing code by refactoring. It simply becomes too difficult. The inevitable result is the code can't benefit from 20 years of advancements in software engineering.

Somebody please tell me this is wrong!

[marioalexis]

I may not explain clearly.
In general, the methodology is this:
Suppose you have a C++ class named MyClass developed in the files MyClass.cpp and MyClass.h, and you want to expose it to Python.
From a file MyClassPy.xml (which contains, among other things, the names and documentation of the methods and the information of the C++ class that you want to export to Python), the files MyClassPy.cpp and MyClassPy.h are created in the build directory. These files contain the structures needed to get the Python/C++ interface.
On the other hand, in the source directory, the file MyClassPyImp.cpp must contain the implementation of the functions that you want to expose. This is where you make the calls to the MyClass functions that you want to work with.
Actually, the .xml files only serve to generate a very generic code needed for the interface where only names and certain characteristics of the functions are provided. The implementation itself is found in the file MyClassPyImp.cpp, in the source directory.

[Kunda1]

ooh...pretty please update Exposing_Cplusplus_to_Python page

[FreddyFreddy]

I may not explain clearly.

Actually you are being very helpful.

So during the build MyClassPy.cpp and MyClassPy.h are generated from MyClassPy.xml specification, and become the interface from the python side. These do not reach into cpp codebase, other than via MyClassPyImp.cpp (below).

MyClassPyImp.cpp is the interface between the cpp codebase and the MyClassPy.x files.

Am I right then in saying that refactoring in cpp eg method name change, will likely not immediately break stuff, except that if method names change, that will not propagate to the python side and would be confusing. A call to a method from MyClassPyImp.cpp is about the only clue in an IDE.