On 7 January 2011 23:20, Thomas Paviot <tpav...@gmail.com> wrote: > 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. > DId you get that to work?
> > >> - 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. > It doesnt have to be that much work. the naming convention is quite consistent, the name of the contained class is always spelled in full after Array1Of.... matching these and extracting the class name should give enough information to build specialized wrappers for the collections. i already have the code working for doing that. but this only solves half of the problem: when occ returns a collection class. I'm still not sure what is the best way to handle python collections passed to functions requiring a OCC collection as argument. We could simply generate the code to convert a python collection to an occ collection, but its a bit wasteful & intransparent if the list is quite large. > > >> - 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. > I dont know how the underlying relation between the gp classes and their corresponding Geom classes is exactly, but all (?) Geom classes has a method that returns a corresponding gp class. so in that case i would say Geom absorbs gp. So maybe we could get away with retrieving the gp object from the Geom object whenever a class that accepts a gp objects recieves its corresponding Geom object. Similarly a gp_Pnt contains a gp_XYZ (again, dont if the XYZ is created or is actually where the Pnt coordinates are stored) > > - 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. > True, but for consistency it would be nice to handle that on a lower level to avoid duplication. But i think this is the trickiest one to solve without too much manual work. > > >> - 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. > Hmm. Why is that? dont remember exactly how typemaps worked (dont answer that one yet, should read a bit better through the swig docs first) Alternatively we could generate conversion code instead of typemaps no? i guess the big issue is identifying the methods where the argument is a 'return pointer'. but we could specify a list of the methods that could be updated over time as they are discovered (if i remember they cannot all be identified by their signature like the &ints and &floats) > > >> - 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). > Thats a pity, would really save a lot of typing, could be interesting to make a query to see how many classes there actually are with duplicate names and whether they are classes that would need to be instantiated at the pythonocc level, or whether they are 'internal' or abstract base classes. if that is the case perhaps we could afford a little inconsistency by prefixing those classes? > > >> - 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. > I'll take a look at that branch. noticed that swig was not so fun, but managed to get around a bit back then. I'll take a look at the code i wrote this summer too and add some more comments if necessary, then i can send you a copy/commit it to the branch so we can see how we could combine that. Think the generator would need some refactoring if we want to start adding more specific handling of different classes, but i might have been shooting birds with cannons when i did the refactoring of your code. Henrik Thomas > > > > _______________________________________________ > Pythonocc-users mailing list > Pythonocc-users@gna.org > https://mail.gna.org/listinfo/pythonocc-users > >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
