Hi Thomas, Frank,
Here's two functions that help you move a python list or list of lists
to their corresponding OCC types.
These work well and generically.
Until we find a more pythonic approach this is pretty practical.
-jelle
def _Tcol_dim_1(li, _type):
'''function for 1-dimensional TCol* types'''
pts = _type(0, len(li)-1)
for n,i in enumerate(li):
pts.SetValue(n,i)
pts.thisown = False
return pts
def _Tcol_dim_2(li, _type):
'''function for 2-dimensional TCol* types'''
length_nested = len(li[0])-1
pts = _type(0, len(li)-1, 0, length_nested)
pts.thisown = False
return pts
for n1,i in enumerate(li):
for n2,j in enumerate(i):
pts.SetValue(n1,n2,j)
return pts
a1,a2,a3,a4 = [],[],[],[]
a1.append([gp_Pnt(1,1,1),gp_Pnt(2,1,2),gp_Pnt(3,1,1)])
a1.append([gp_Pnt(1,2,1),gp_Pnt(2,2,2),gp_Pnt(3,2,0)])
a1.append([gp_Pnt(1,3,2),gp_Pnt(2,3,1),gp_Pnt(3,3,0)])
a2.append([gp_Pnt(3,1,1),gp_Pnt(4,1,1),gp_Pnt(5,1,2)])
a2.append([gp_Pnt(3,2,0),gp_Pnt(4,2,1),gp_Pnt(5,2,2)])
a2.append([gp_Pnt(3,3,0),gp_Pnt(4,3,0),gp_Pnt(5,3,1)])
a3.append([gp_Pnt(1,3,2),gp_Pnt(2,3,1),gp_Pnt(3,3,0)])
a3.append([gp_Pnt(1,4,1),gp_Pnt(2,4,0),gp_Pnt(3,4,1)])
a3.append([gp_Pnt(1,5,1),gp_Pnt(2,5,1),gp_Pnt(3,5,2)])
a4.append([gp_Pnt(3,3,0),gp_Pnt(4,3,0),gp_Pnt(5,3,1)])
a4.append([gp_Pnt(3,4,1),gp_Pnt(4,4,1),gp_Pnt(5,4,1)])
a4.append([gp_Pnt(3,5,2),gp_Pnt(4,5,2),gp_Pnt(5,5,1)])
bezier_input = [_Tcol_dim_2(i, TColgp_Array2OfPnt) for i in
[a1,a2,a3,a4]]
harray = []
harray.append(P1.Translated(gp_Vec(4,0,0)))
harray.append(P2.Translated(gp_Vec(4,0,0)))
harray.append(P3.Translated(gp_Vec(4,0,0)))
harray.append(P4.Translated(gp_Vec(4,0,0)))
harray.append(P5.Translated(gp_Vec(4,0,0)))
aaa = _Tcol_dim_1(harray, TColgp_HArray1OfPnt)
On Mar 27, 2009, at 6:49 AM, 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
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
