Hi Bryan, My feeling is that the discussion is getting a little out of control; the renaming we have in mind isn't a big deal really. As far as I'm concerned there is only one option that is worth considering ( renaming classes / methods is _not_ acceptable ) Which is moving from `from OCC.BRep import * -> from OCC import BRep`. That's all there is to it.
Changing methods would turn the documentation into a heap of garbage, so that's *really* not acceptable. However, it is fruitful as a community to discuss these in-depth, and I thank you all for your ideas. I hope that in the not too distant future, the Level2 api ( the pythonic API we're working on, think of Topology.py as an example ) will become the dominant API for pythonOCC. Where increasingly, one has to use the Level1 api less and less often. A syntactic difference between Level1 and Level2 therefore is a useful idea. This way you will be informed at what level you're working. Level1 would follow OCC's CamelCaps, where Level2 will follow python coding standards ( lower_case_with_underscores_method_calls, see http://www.python.org/dev/peps/pep-0008/ ). Regarding lazy imports; we've thought about this too, but I don't think its a good idea. To be able to work well with pythonOCC ( anything that has tens of thousands of methods really ), IDE support ( happy to hear your a Pydev fan too ;') is critical. Adding lazy imports is another firewall that very well might hinder IDE support ( it would break in Pydev ) so I'm not much in favor of that. Thomas just informed me that the ( pretty trivial ) renaming mentioned above would take him just 4 or 5 lines of code in the wrapping mechanism. I hope you can follow and agree with our reasoning here. ( I continue to be amazed with your Traits work Bryan ;') Cheers, -jelle On Apr 29, 2009, at 10:51 AM, Bryan Cole wrote: > Thankyou everyone for the feedback. > > After the interesting discussion, and Thomas' encouragement in > particular, I'll work on this. It may be a week or two before I have > any > results to show (I'm anticipating a particularly busy week, so OCC > work > is confined to my spare time). > > Regarding the question of python lazy imports and naming conflicts, > I am > sure conflicts would occur. For example: > > gp_Circle vs. Geom_Circle > > However, I understand that it is standard python practice to avoid > lazy > imports (I certainly do) except in limited circumstances such as an > interactive terminal session. Really, we are removing the need for > lazy > imports: the correct and simplest way to distinguish the two Circle > classes is by their package prefix i.e. gp.Circle() vs > Geom.Circle(). We > should certainly make this clear in the docs for the benefit of new > python users. I expect experienced python programmers will follow best > practice by default. You also gain a little more flexibility this way, > since python allows you to rename modules on import i.e. > > from OCC import gp, Geom as G > c1 = gp.Circle() > c2 = G.Circle() > > Raising a warning or exception to prevent import * seems slightly > draconian, although this wouldn't inconvenience me personally. > > cheers, > > Bryan C _______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
