A follow up of Henrik's post dealing with pygccxml, forked from the so long but fundamental 'Anyone seen this?' thread! And comply with Henrik's wish to be 'clear what the purpose of the discussion actually is' . Hope this posit is clear enough ;)
Inserted my comments with priorities from 1 to 3 (1: low priority, 3 high priority). A while back i was playing around with pygccxml (a c++ parser that can be > used for code generation) to get an idea of what could be done to make > opencascade more user friendly without having to manually write all the > wrappers. There are quite a lot of things that could be done with the > wrappers to make them more compact and 'pythonic' without manually writing > all the code: > > - Handles (i believe Thomas managed already to get rid of those, havent > tested that) > P:3 I actually played with that to remove the Handles_* from the wrapper. It can be achieved at the SWIG level. The object<->conversion can be defined as aSWIG %template. > - The collections classes: Array1Of.... the methods of these classes could > be rewritten to conform to the list/set/etc interfaces of python and all > methods that accept these collections could have some aout generated code > that converts standard python lists to these classes if necessary (i already > have the code to identify all the collection classes) > P:2 Can be performed at the SWIG level. Use %typemaps. Problem: there are *many* different Array1Of, Array2Of etc and this will be a long work. > - The strictness of arguments in general could be loosened or some > classes could be merged ( for example gp_Pnt/gp_XYZ/gp_Vec/gp_Dir) are > basically the same thing > P:1 Not at the SWIG level. > - Geom and gp could be merged or autoconverted between > P:1 Same as previous. "Merge is not clear". If you wish to 'merge' A and B, do A absorbs B or the opposite? Or you can choose to inherit A and B from C, but you have to create another class on top of the previous one, and I know you don't want to build any additional data structure on top of the OCC data model. autoconversion from Geom to gp could be possible at the SWIG level. - A lot of the algorithms classes that need to be initialized, executed and > then a method call to return the object of interest follow similar patterns > that could merged into a single method call, for example the sequence: > cut = BRepAlgoAPI_Cut(shape1, shape2) > cut.Build() > cutted_shape=cut.Shape() > There are already a few functions like that available in the OCC.Utils directory. > - There still are a lot of method calls that takes a pointer to an object > that serves as the return value > P:3 Right. Doable in SWIG, using %typemap. But 'lot of' methods mean 'lot of' time to develop, since typemaps cannot be generated from pygccxml but have to be written manually. > - We could add a simple regexp to rewrite the CapitalizedMethodNames to > pythonic_underscored_method_names > P:1 Why not. Can be simply achieved with SWIG and the %rename directive. > - Eliminate the prefix of all the classes and implement them as python > namespaces: > Geom_Point -> Geom.Point or > from Geom import * > p = Point(...) > Already tried but gave up with that. For instance, you have AIS_Shape and TopoDS_Shape classes. With such renaming, from AIS import * and from TopoDS import * would conflict. And it's just one example among many (thousands of classes are defined in OCC). > - then there is a lot of adapters etc that i havent looked too much at. > > Many of these patterns can be identified with pygccxml queries and used to > add code to the wrappers. Some would require manual specification of classes > and methods that belong to a pattern. > > Im not sure i would call it a high level api anymore, but i think it would > alleviate a lot of the need for a general high level api. > Well, let's stop with this 'high level api'. It would just be 'more pythonic', and I agree on that point. > what do you guys think? > This is how I work with the SWIG wrapper : - manual modification of existing SWIG files : I usually run the test with the Standard module. - when I checked that it work, I modify the 'SWIG_generator' file in order to generalize the modification to all SWIG files - I recompile the whole pythonOCC. There are usually many files that do not compile, little tweaks, special cases etc. It's the most difficult part, and the longest one (there are more than 200 modules to check). I have to warm you that working with SWIG is quite difficult: you have to dive into C++ code, pointers, references, memory issues etc. And a small modification in SWIG files can introduce a lot of regressions. In brief, it's not as fun as working with python. In a first step, I would work on the Handle_* issue : removing handles would lead to a massive reduction of the wrapped classes (the half actually) and a big reduction of the compilation time, a reduced epydoc documentation etc. I once created a 'wrapper refactoring' branch on the svn repository. It can be used to test these developments. Thomas
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
