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
