Henrik Rudstrom
On 10 January 2011 11:08, Thomas Paviot <tpav...@gmail.com> wrote:
> Jelle,
>
> I agree with most of your arguments. However, there are two points that
> have to be remained:
> - OCC is about to release the version 7.0 of its technology. If we want to
> stay sync with latest OCCT version ( that's something that must be
> discussed, but I think we should), this will introduce a change in the API.
> We dont know yet what will the changes be, but they might be quite
> important. So in a sense, we do not control the API stability (in terms of
> classes/objects/functions etc.) since we rely on a C++ library and there
> will necessarily be modifications to the pythonOCC API. This could be an
> opportunity to add new features to the wrapper ;
> - Henrik would like the wrapper to be more pythonic at the SWIG level
> because he is not satisfied with the current implementation. He thinks he
> would be more productive with this changes, and his arguments are good. I
> can hear this request from a pythonocc user, and understand it.
>
> So, a good way to deal, at the same time, with your arguments and Henrik's
> ones, would be to make the wrapper *customizable*. Let me explain : in the
> current implementation, SWIG files are provided as-is. Everyone downloads
> the same .tar.gz archive and compile its pythonocc. As a result, everybody
> runs the same pythonocc, which is quite convenient to discuss issues, fixes
> etc. However, some people may want to be more comfortable with their
> pythonocc, even if it's not exactly the same as the other users. For
> instance, it should be possible to wrap only a few modules among the
> available ones. And Henrik could, if he wants, wrap the C++ functions with
> its low_level_case naming convention. We could imagine a few optional flags,
> disabled by default, in the installer, to enable methods renaming to
> low_level_case, or imagine a graphical user interface, with checkboxes, to
> select the modules to wrap (leading to a 'smaller' pythonocc, that includes
> only the features that are really used by the program running on top of it)
> . Whenever anyone use such 'customized installer', he has to be warmed that
> 'You're about to install/compile a non standard pythonOCC. As a result, you
> may loose compatiblity with other pythonocc users and have difficulties to
> request for any help or support. Do you want to continue (Y,n)?". On our
> side, we would continue to distribute and maintain a 'standard' pythonocc
> distro, with all modules available, CamelCase methods etc. Let's leave
> people here use pythonocc as they want.
>
What if we could add customization at load time as well, like a pluggable
front-end. This could be generated python code that dynamically create a
parallel module namespace and renames the classes and methods.
then the user can choose to globally enable Pure OCC, pythonic or both
coding conventions
one drawback is that this has to be set project wide (so also for included
files) since the class objects cannot be duplicated (as far as i know), so
if a user enables both coding conventions, every class has a duplicated set
of methods
if we make a new root namespace for the pythonic api. lowercase 'occ' for
example. these could coexist peacefully.
OCC.BRepBuilderAPI.BRepBuilderAPI_MakeFace <-> occ.BRepBuilderAPI.MakeFace
Most likely many IDE wouldnt be so happy with this. so compile time
customization would still be needed to express personal coding preference.
#file occ.py
from types import *
import OCC.Geom
Geom = ModuleType('occ.Geom')
Geom.Point = OCC.Geom.Geom_Point
setattr(Geom.Point, 'x', Geom.Point.X)
strict = True
if strict:
delattr(Geom.Point, 'X')
>
> Thomas
>
>
> 2011/1/9 jelle feringa <jelleferi...@gmail.com>
>
>> Thomas, Henrik,
>>
>> Please do not be overly prudent with the SWIG operations.
>> I'm speaking here with regard to the semantic implications of some if what
>> you've been discussing
>>
>>
>> The *worst* thing a reasonably mature project can do is to dramatically
>> change its API ( from CamelCamps to pep_8 is dramatic ). It *
>> unnecessarily* breaks existing code for no real gain. A well esthablished
>> project like pythonocc should _never_ do those things. That breaks a lot of
>> pythonocc code out there.
>>
>> Here are some reasons why I do not like to see too many _semantic_ changes
>> in the API on the level of the wrapper:
>>
>> 1) it breaks existing code
>> 2) it breaks a relative compatibility with C++ pythonocc code. this is
>> important; this compatibility makes it trivial to use C++ code. OCC experts
>> on the OCC forum can still read pythonocc code, even if they are C++ coders
>> themselves.
>> 3) making pythonocc pythonic is something done at *python *level, only to
>> a certain extent at the C++ level
>> 4) when I read BRepPrimAPI_MakeBox, I *know* I'm using OCC at a low, OCC
>> idiomatic level, if I see make_box ( OCC.Utils.Construct ) I know to expect
>> a pythonic API. this is very important; so far, even very mysterious bugs
>> have been easy to hunt down since we've kept a very clear semantic
>> separation, which is a big deal, since you clearly can understand when
>> something fails if its at the python level or at the wrapper / C++ level.
>> 5) the current python pythonocc code is relative consistently with this,
>> but not absolutely. Can I suggest a refactor for the upcoming 0.7 release?
>> 6) don't get me wrong; it would be great if pythonocc's wrappers would
>> accept any python iterable other than the horrible typed OCC containers (
>> think TCollection_gp_vec_List ), still this _would_ create a certain
>> confusion, right?
>>
>> So, I'm all for improvement, but I hope you agree with me that these
>> points are very important too.
>>
>> Cheers!
>>
>> -jelle
>>
>> _______________________________________________
>> 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
>
>
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
