Hey Thomas and Jelle, Good to hear your opinions Jelle, and I see that code breakage is a major issue.
Still i think there are ways to deal with that. One of course is to allow customized wrapper generation, but i fear that would create a separation in the community, and i wouldn't want to be the cause of that. My main motivation for this thread would be to compact the api by reducing the need for and extra layer on top, not cause divergence. An alternative to Thomas' proposal could be to generate a set of method aliases in every class (class names wouldn't need to be renamed for pep_8), so that the users can still choose, while remaining compatible with users of another case convention. _If_ we eventually agree to move to pep_8, we could make a deprecation decorator to the original CamelCased methods. If the user wants to rewrite his code to conform to pep_8 a global flag could be set that can generate a copy of the source file where the deprecated methods are called, with added comments where the deprecated methods are called. That should make the conversion quite simple. (something like this<http://wiki.python.org/moin/PythonDecoratorLibrary#Smartdeprecationwarnings.28withvalidfilenames.2Clinenumbers.2Cetc..29>, but instead of logging the message, it would be appended to the correct line in the copied source file) Also would like to comment on some of Jelle's points: > "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." If it improves the usability and the learning curve of pythonocc i wouldn't say it is unnecessary. Isn't ease of use the main reason for porting a c++ library to python? Also, if we choose to break some eggs doing that, it is better to do it earlier than breaking even more eggs later. > 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. In VTK (from what i remember, one of your favorite libs ;) ) they have a CamelCased C++ api, and a pep_8 python api. As long as the conversion between CamelCase and pep_8 is consistent, i dont think it should create a big issue for readability. Also, if we choose to keep the the wrapper layer as it is. It would create a need for much more utility-functions/'high level api', and if that also is the recommended way for using pythonocc, the conceptual distance between OCC and pythonocc would be greater than if we make the wrappers themselves more pythonic by a set of conversion patterns in the wrapper. Would be interesting to hear other user's opinions on this issue. Is the pain of changing existing code worth the increase in productivity on the longer term (if any?). Also, the pep_8 conformance is just one of the improvements we discuss, Jelle: would be nice to hear your thoughts on the other suggestions as well. 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. > > 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
