> I like your suggestion. It makes the code more compact (which seems > like > a pythonic kind of idea) and less redundant. I think it makes code > more > readable too. The only drawback I see is that it departs pythonOCC > code > further from straight C++.
I don't see how Arthur? We're not renaming the actual classes, just the way these are grouped together in a module. It could be done something like: _some_.so _some.py some.py ( -> from _some.py import * ) That would fix the situation as is. This is the simplest fix I can think of. > I don't think this as such a big issue, but > maybe I would change my mind if I was porting from pythonOCC to OCC. Its *absolutely* an important issue that the SWIG wrappers ( Level1 ) feel like the C++ api, you're absolutely right. This way the existing OCC knowledge is kept intact, which is critical. Modules like OCC.Utils.Topology hint at the pythonic ( known as Level2 ) API. I'm working on this right now, but really is work in progress. > I have no idea about how difficult this is to do with SWIG. If you > know > how to do it, that's cool. Its not really nessecary to do this in SWIG, see the above. I think I've learned this trick from the WX guys. -jelle _______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
