Thanks Thomas and Jelle for the explanation and examples. I will be
using all OCC collection classes for now, although I'm really looking
forward to your eventual Pythonic wrappers!
Cheers,
Frank
Thomas Paviot wrote:
>
>> 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
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
