2011/1/7 Thomas Paviot <tpav...@gmail.com>
> 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.
>
And a python function to convert methods names from CamelCase to lower_case.
This simple one should do the job:
import re
def CamelCase_to_lower_case(name):
s1 = re.sub('(.)([A-Z][a-z]+)', r'\1_\2', name)
return re.sub('([a-z0-9])([A-Z])', r'\1_\2', s1).lower()
>
>
>> - 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
>
>
>
Thomas
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
