> When using pythonocc, is there any reason for using OCC's list,
> sequence, and map classes instead of Python's built-in list and dict types?
>
> For example, if I wish to collect shapes to operate on, is there any
> reason to use TopTools_ListOfShape instead of a Python list (assuming
> the list of shapes is only used/accessed on the "Python-side")?
>
Hi Frank,
Thanks for asking this question! It's for me the opportunity to explain
the development process before I answer.
The primary goal of pythonOCC was to provide a Python wrapper to
OpenCascade 6.3.0 that would be *as close as* possible to the original
C++ library. This way, it would have been very easy to move from Python
to C++ code or the opposite. For instance, if you ever tried to port a
C++ sample to pythonOCC, you can notice it can be done in a few minutes:
in a sense, you just have to remove '{};' from C++ and copy/paste to
your Python IDE. pythonOCC can be then considered as a rapid prototyping
OpenCascade application.
The problem is that if you want to stay close to the original API, two
mechanisms are *not pythonic* at all. I mean:
(1) OpenCascade memory management: smart pointers/reference counting,
(2) Strong typing.
The point (1) is critical. Much improvements have been made these last
weeks: the 0.1 release was almost unusable, and the samples that were
recently added require the latest svn rev. to properly run. The memory
segfaults are fixed, there is still some work to do to reduce memory
consumption.
Consequences of the point (2) are that you have to use OpenCascade
arrays and cannot use Python built-in types (lists, dicts). For
instance, if you want to create a BSpline from a set of points, you have
to do:
P1 = gp_Pnt(0,0,1)
P2 = gp_Pnt(1,2,2)
P3 = gp_Pnt(2,3,3)
array = TColgp_Array1OfPnt(1,3)
array.SetValue(1,P1)
array.SetValue(2,P2)
array.SetValue(3,P3)
SPL1 = GeomAPI_PointsToBSpline(array)
If it would really pythonic, then we should have to do something like:
P1 = gp_Pnt(0,0,1)
P2 = gp_Pnt(1,2,2)
P3 = gp_Pnt(2,3,3)
array = [P1,P2,P3]
SPL1 = GeomAPI_PointsToBSpline(array)
That would be quite more elegant and allow to access list methods (sort,
reverse, pop etc.) that are so useful. It's not so hard to implement
with SWIG, and many howtos are availble to deal with Python lists and
C/C+ arrays. But it wasn't, untill now, the priority: all development
time and energy was focused on memory management, module extensions and
portability. The last two points are almost achieved, memory needs a few
work. We can now think about pythonOCC API polish. This is then how I
see the few coming weeks/months of work:
* First point (high priority): pythonOCC must be as memory safe as
OpenCascade. It's not yet the case.
* Second point (medium priority): make pythonOCC more pythonic, that is:
- completely hide memory management stuff to pythonOCC users: things
like smart pointers, OCC Handles or DownCasting have nothing to do with
python idioms,
- make a better use of built-in python types to handle OCC lists and
arrays.
The consequence of this second point is that the pythonOCC API will be
quite different from OpenCascade: the port from C++/Python or Python/C++
will be less natural and simple. But maybe it's time that pythonOCC live
its own life, I mean build its own 'personality' and break free from all
these stupid C++ things that made us become python lovers!
> Thanks,
> Frank Conradie
>
Best Regards,
Thomas
_______________________________________________
Pythonocc-users mailing list
[email protected]
https://mail.gna.org/listinfo/pythonocc-users
