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. 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
